Just a few ideas... CMS is not a compacting collector, which can result in old generation fragmentation: if there will be any memory leaks in the connection's resources that makes the old generation filled with fragmented garbage, a FullGC (with no results due to the leak!) is triggered to compact the live tenured objects and a “promotion failed” message will be logged. Hence, having any GC logs and jmap (or using any profiler) heap histograms in different moments during the application lifetime (before and after a GC would be great) could help to know if the memory leaks theory is valid.
Leaving alone the memory leaks theory, maybe the CMS collector is not "fast" enough to keep the pace,hence it could make sense to help it to be more "proactive" while starting to concurrent collect garbage (by default the threshold to start a concurrent collection is 70%!): try providing more headroom (1 GB more!) in OldGen (using -XX:NewRatio) and lower the threshold to start a concurrent collection with -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 With this configuration CMS could be able to collect all the garbage in time to let happen further promotions (and new connections too:) ). About the throughput collector (default parallel GC): > old gen was filling up without full GC being run Do you mean that the old gen is full and no Full GCs happens? AFAIK when the old gen is filled up of "real" resources (ie can't be collected) and a new promotion/allocation will occurs you would have a GC log similar to this: [GC (Allocation Failure) 2661502K->2638903K(2715648K), 0.0127080 secs] [Full GC (Ergonomics) 2638903K->2638545K(2715648K), 0.0996147 secs] [GC (Allocation Failure) 2638545K->2638545K(2715648K), 0.0158627 secs] [Full GC (Allocation Failure) Exception in thread "main" 2638545K->2638180K(2715648K), 0.0329988 secs] java.lang.OutOfMemoryError: Java heap space It is strange the GC doesn't happen at all or I've missed something? Anyway, having a test case or Heap/GC stats could be really useful to help to understand what is happened, there really too many cases to be covered! -- View this message in context: http://activemq.2283324.n4.nabble.com/Artems-ParallelGC-vs-CMS-tp4721722p4721743.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
