Your efforts are focused on the wrong JVM. The broker's fine, and your webapp is not, as shown by the two screenshots you shared.
On the broker side, what you're showing looks like perfectly normal JVM garbage collection, though it looks like Young Gen is only 3/8ths of the full heap, which is lower than I'd want it. The brokers I've monitored generally didn't keep messages for very long, so most memory that was allocated was generally garbage by the time GC ran, so I wanted Old Gen to be smaller and Young Gen to be larger. In my experience, ActiveMQ itself generally used ~100MB, so 500-750MB of Old Gen would be the most I'd want. But JVM tuning is more art than science and a lot depends on your situation, and until it's not working well sometimes there's no point changing it, so for now I'd leave those settings along. (Especially since you're both new to the project and an intern.) So there's nothing to see here. On the webapp side, your JVM is spending nearly all of its time trying to GC you down below 800MB but only succeeding in freeing up at most 100MB at a time. If the same percentages are in use as for the broker, you'd be GCing anytime you got above 375MB, which means that you're continually GCing. That's bad. You need to raise the threshold at which the JVM GCs to a higher value, so that some objects can build up (and die) in memory and all be GCed together in a batch. From this 35-minute graph, 950MB or maybe even as high as 975MB would probably be OK, but it's hard to extrapolate from 35 minutes of observation and claim it would be safe in all situations and at all times. Another option would be to increase the JVM size to something like 1.5GB, setting the GC threshold at maybe 1.3GB or 1.4GB. If you're not familiar with JVM GC strategy tuning, you should read up on how garbage collection works in general, and on what strategies are available in your particular JVM version. The good news is that you don't appear to have a memory leak, otherwise you'd see the post-GC memory usage rise over time. So you can ignore the DeserializerCache unless you see something to indicate that the memory taken by live objects is increasing consistently over time. On Tue, Sep 22, 2015 at 11:47 AM, mhempleman <matthew.hemple...@alstom.com> wrote: > FYI the image from the previous post was for the ActiveMQ process. This is > the application process: > > <http://activemq.2283324.n4.nabble.com/file/n4702192/cpuMem2.png> > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Garbage-collecter-out-of-memory-tp4702160p4702192.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
