Jano wrote: > Jano wrote: > >> Matthew Toseland wrote: >> >>> [B [I [C [[B almost certainly mean byte[], int[], char[], byte[][]. >> >> Good to know. >> >>> I didn't get jmap to work (maybe because I was using java 5), but I did >>> do some invasive profiling (with stack traces), and used that to >>> identify and eliminate some high-churn objects; if the current problem >>> is that too much garbage collection is occurring (causing 100% cpu >>> usage), this is most likely caused by too many objects being allocated >>> per second. >> >> FWIW, I have the OoM problem but not high CPU problems (see my graphs >> pending moderation). >> >> Though, as the point of OoM gets closer, the JVM will attempt a full OoM >> each time it would run out of memory, so I'd say that in the final >> moments of a node, CPU churn due to GC will be very high (I'll try to >> capture these moments with jconsole, very nice tool). > > It seems I was wrong. From the graphs I attach I'd say that the JVM didn't > attempted very aggresively to GC before signaling OoM. This was a node > configured with 256m. As you can see, CPU was never a big issue, and I had > around 50 insertions running. My cpu is a dual core 2.8GHz one.
Seeing this other graph of the 96m node, it seems that what happened is that the graphs didn't had enough resolution. This other node has died rather quickly, and the cpu stress when the JVM is desperately GCing in its last moments is rather evident. Also, I think that my CPU usage tops at 50% because of the dual core thing (the JVM only takes advantage of one of them?) I'm going to test now a standard 128m node with no insertions nor clients running... -------------- next part -------------- A non-text attachment was scrubbed... Name: death96m.gif Type: image/gif Size: 25025 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070205/38797060/attachment.gif>
