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 09:50:01 GMT
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