-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kees Jan,
Kees Jan Koster wrote: >> JVM >> Free memory: 38.13 MB Total memory: 111.18 MB Max memory: 1365.37 MB > > As David pointed out, this is probably measured against the committed > memory, not the max memory. I believe that "committed" and "total" are identical. From the above info, it looks like the JVM is using about 70MB of it's own heap. If you asked top or ps what the JVM was using, it would say 111MB + whatever non-heap memory has also been allocated. [OT from here on out] > I just wrote a small post about memory leaks > http://java-monitor.com/forum/showthread.php?t=150 In that post I also > talk about the difference between maximum memory and committed memory. Note that in the memory usage graph you show, the leak is certainly not "easy to spot". In fact, that memory graph looks perfectly healthy to me: lots of little GCs and a full GC every 18 hours or so. The reason the memory curve looks good to me is that, after every full GC, the amount of used memory is lower than the previous full GC. Unless you have the graph labeled incorrectly, this graph looks good to me. PS MarkSweep "overtakes" PS Scavenge late on the 12th because the JVM is doing a full GC, rather than the frequent incremental GCs that it always does. This does not "signal an impending out of memory situation". I have a graph that looks pretty much just like yours: used memory bounces between 30MiB and 160MiB with a fixed maximum of 192MiB, incremental GCs all the time which makes the long-view of the graph seem "fuzzy", and full GCs every 30 hours or so. The full GC takes the used memory from ~160MiB all the way down to maybe 40MiB (that's a lot of garbage!). This went on for 6 weeks until I decided to stop graphing it because I was convinced that my new memory settings were sufficient (I had recently run out of memory when running with the default 64MiB heap). I *do* recommend setting the min and max heap sizes to the same value: this allows the JVM to used fixed generation sizes and not waste its time re-allocating and re-arranging the whole heap whenever it's going to expand it. If you don't need a huge heap, why even set it as the maximum? If /do/ need a huge heap, why not allocate it all at once? > You could hook your Tomcat up to Java-monitor. Java-monitor tracks you > memory usage over two days, so you can see how the memory usage develops > over time. The graphs in the post are made with Java-monitor. Or you could use a spreadsheet and not publish your usage data to the world. :( - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklFK+MACgkQ9CaO5/Lv0PAeAwCfRnv0VhQtaEoMFqbyXGyMoc5U PogAoIYWJ5h6jd1Uk9O8T+ZRZ+jRISnd =4ZJH -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
