activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Garbage collecter out of memory
Date Wed, 23 Sep 2015 13:34:36 GMT
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

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 <>

> FYI the image from the previous post was for the ActiveMQ process.  This is
> the application process:
> <>
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message