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.char...@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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
