My brain swapped the units in your description, to an 8 minute GC with unresponsiveness 15 seconds later. Sorry for the confusion.
8 seconds is long, but not unheard of, especially if the heap is large. G1 aims to shorten the Old Gen GC pause time by doing multiple small GCs of Old Gen rather than a full GC (though it'll fall back to a full GC if the incremental Old Gen collects don't work for some reason), so you you might be happier with it if you care about pause times. But I'd have expected lots and lots of full GCs if you were hitting CMS's failure mode, so GC no longer sounds like our problem. Can you use JVisualVM's CPU sampler (attach via JMX) to see what the broker is spending its time on when you're in the unresponsive state? That might give us more information. Tim On May 19, 2017 3:42 AM, "Shobhana" <shobh...@quickride.in> wrote: > Tim, full GC takes 8 seconds, not 8 minutes. > > Also, after full GC, large amount of memory is reclaimed (13G to <2G) : > > 2017-05-17T14:01:46.179+0530: 34205.488: [Full > GC2017-05-17T14:01:46.179+0530: 34205.488: [CMS: > 13039360K->1895795K(26214400K), 8.5260340 secs] > 13578056K->1895795K(27158144K), [CMS Perm : 33865K->33826K(131072K)], > 8.5261390 secs] [Times: user=8.87 sys=0.00, real=8.52 secs] > > Considering so much memory is freed up, do you think fragmentation would > still be a cause for concern? I checked for size of few objects in histo > report but couldn't find any object greater than 1.5KB. > > Haven't used JConsole, but from GC logs I see just one or 2 full GCs before > broker becomes unresponsive. > > I'll also try by switching to G1GC and see if it makes any difference. > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/ActiveMQ-broker-becomes-unresponsive-after- > sometime-tp4725278p4726390.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
