I've never observed the JMX-related memory issues you described in the brokers I've worked with (though they were all older: 5.10.x and before). Maybe a bug was introduced in a recent version, or maybe something during your testing looked more problematic than it actually was.
Your CPU usage doesn't look bad, and if you were stuck doing so much GCing that the broker stopped responding, I think the CPU would be much higher than that. But hopefully you'll have more info from what you see in the GC logs. Unresponsiveness with low CPU utilization could indicate lock contention (which would show up in a thread dump) or disk or network I/O (which you can detect via system monitoring tools), so I'd look there if GC doesn't appear to be the culprit once you get those logs in place. The fact that deleting the KahaDB files clears things up temporarily makes disk I/O a prime candidate, but it could be any of the three (or something else entirely). Tim On Thu, Apr 27, 2017 at 10:26 PM, Shobhana <shobh...@quickride.in> wrote: > Thanks for your quick response Tim! > > The top command yesterday showed the following after the broker became > unresponsive : > a) CPU usage : 15 min avg was 1.2 cores > b) Memory % : ~35% > c) KiB Mem : 32948228 total, 25744576 used, 7203652 free, 51704 buffers > > Today I'll capture necessary data periodically and observe for any > differences. I'll also enable capturing GC logs and check for any hints > from > there. > > Long back we had enabled JMX, but we had observed some scalability issues; > when we checked heap dump we found many JMX related objects and hence > disabled JMX. > > If I cannot identify anything useful from data collected periodically or > from GC logs, I'll enable JMX for sometime to check the health of broker. > > > > -- > View this message in context: http://activemq.2283324.n4. > nabble.com/ActiveMQ-broker-becomes-unresponsive-after- > sometime-tp4725278p4725294.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
