james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: OutOfMemory exception
Date Thu, 01 Apr 2010 15:49:25 GMT
Hi Eric,

its me again ;) Could you please svn up to latest trunk and try again ?

Thx,
Norman

2010/4/1 Norman Maurer <norman.maurer@googlemail.com>:
> Hi Eric,
>
> I did a stress test in the last few hours (running in the background
> here) and I was not able to get a OOM yet with
> "?broker.useJmx=false&amp;jms.prefetchPolicy.all=1" for the
> jmsConnectionFactory. I sent 40000 emails with 100k to it and 3000
> with 5 mb.
>
> I'm using -Xmx512m and memory usage is not getting higher then 700m.
>
> Bye.
> Norman
>
>
> 2010/4/1 Eric Charles <eric.charles@u-mangate.com>:
>> Tks Stefano for the precisions.
>> I keep these in mind and already took last week some head dumps via
>> -XX:+HeapDumpOnOutOfMemoryError and jmap.
>> I have to further analyze the dumps and run full profiling this weekend.
>> For sure increasing the memory will still produce a OOM, but I have a bit
>> more time before process crash.
>>
>> Tks a lot,
>>
>> Eric
>>
>>
>> On 04/01/2010 09:44 AM, Stefano Bagnara wrote:
>>>
>>> 2010/4/1 Eric Charles<eric.charles@u-mangate.com>:
>>>
>>>>
>>>> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Java
>>>> exception: 'Java heap space: java.lang.OutOfMemoryError'. {prepstmnt
>>>> 1363215207 INSERT INTO Message (id, bodyStartOctet, content,
>>>> contentOctets,
>>>> [...]
>>>> So still a OOM exception that was shown by yet-another-component (in this
>>>> case, the StoreMailbox).
>>>>
>>>
>>> OOM are shown by whichever component needs memory once the memory is
>>> exausted. So there's almost no point in taking into consideration the
>>> exception stacktrace when an OOM happens in a complex system.
>>>
>>> OOM are the results of (a) real insufficient memory (too big memory
>>> requirements), (b) memory leaks.
>>> So, either some component is configured to use more memory than the
>>> available or some component does not free resources. I guess we are in
>>> (b).
>>>
>>> So, either you go for a full profiler, or you at least take heap dumps.
>>>
>>> We have to know if memory usage grows constantly to OOM, or if you
>>> have very frequent GC that free space but then once in a while it is
>>> not enough and it throws the OOM, if the memory is full of unused
>>> objects from the same class or instead a full tree of different
>>> objects.
>>>
>>> If you don't go for a full profiler, jmap -histo, jmap -dump, jstat,
>>> jmap, jconsole are your friends here.
>>>
>>> Also, add the -XX:+HeapDumpOnOutOfMemoryError parameter to your jvm,
>>> so that you have an automatic heap dump on OOM (you can also set this
>>> "live" with jinfo)
>>>
>>> Also some other "guessed" information can help: the memory usage is
>>> proportional to the processed message? To their sizes? To the uptime?
>>> To the failed message..etc.
>>>
>>>
>>>>
>>>> There were only 4 .m64 files in /tmp (the ValidRcptHandler is doing its
>>>> job).
>>>> All 4 files were 0 bytes.
>>>>
>>>> I have now launched with EXTRA_JVM_ARGUMENTS="-Xms512m -Xmx4g" (so 4GB
>>>> max
>>>> memory).
>>>>
>>>> With the previous parameters ( -Xmx512m), the process was taking the
>>>> whole
>>>> 512MB.
>>>>
>>>
>>> Increasing the memory is rarely of help in this case: this will only
>>> help if we are in the "(a)" scenario (some component configured to use
>>> more memory than we thought). You'll probably get the OOM anyway, but
>>> it will take more time. If this happen we cat then exclude (a) and go
>>> for (b) analysis.
>>>
>>> Stefano
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message