The known fact is that in Java, the long GC pauses usually happen when the garbage collector runs a lot. GC runs to gain the memory again. This long pauses particularly happen when full GC cycles are initiated by two failure actions, either promotion failures or concurrent mode failures. You can get an overview on GC and how the long pauses happen from here
Looking at your log I can say, after a ParNew promotion failure, the CMS collector failed in concurrent mode. This actually forced a stop-the-world full GC which led to freeze the application threads for about 130 seconds. If you notice, you can understand that this long pause is mainly because of GC struggling to reclaim memory quickly from a very full heap or fragmented spaces. Doing this actually worsen the application since it's already handling heavy load. Making a few minor changes like heap size tuning, GC options, or even checking a few new and alternative collectors (like G1) might help in reducing these long pauses and understand which is the best approach to follow.
Looking at your log I can say, after a ParNew promotion failure, the CMS collector failed in concurrent mode. This actually forced a stop-the-world full GC which led to freeze the application threads for about 130 seconds. If you notice, you can understand that this long pause is mainly because of GC struggling to reclaim memory quickly from a very full heap or fragmented spaces. Doing this actually worsen the application since it's already handling heavy load. Making a few minor changes like heap size tuning, GC options, or even checking a few new and alternative collectors (like G1) might help in reducing these long pauses and understand which is the best approach to follow.
Statistics: Posted by jack_002 — Fri Apr 25, 2025 3:44 am