Hi Eric, its me again ;) Could you please svn up to latest trunk and try again ?
Thx, Norman 2010/4/1 Norman Maurer <[email protected]>: > 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&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 <[email protected]>: >> 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<[email protected]>: >>> >>>> >>>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
