JVM CMS 垃圾回收问题

我在具有并发标记扫描收集器的应用程序的 GC 日志文件上看到以下症状:

4031.248: [CMS-concurrent-preclean-start]
4031.250: [CMS-concurrent-preclean: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
4031.250: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 4036.346: [CMS-concurrent-abortable-preclean: 0.159/5.096 secs] [Times: user=0.00 sys=0.01, real=5.09 secs] 
4036.346: [GC[YG occupancy: 55964 K (118016 K)]4036.347: [Rescan (parallel) , 0.0641200 secs]4036.411: [weak refs processing, 0.0001300 secs]4036.411: [class unloading, 0.0041590 secs]4036.415: [scrub symbol & string tables, 0.0053220 secs] [1 CMS-remark: 16015K(393216K)] 71979K(511232K), 0.0746640 secs] [Times: user=0.08 sys=0.00, real=0.08 secs] 

预清洁过程不断中止。我尝试过将CMSMaxAbortablePrecleanTime从默认值5调整为15秒,但这没有帮助。当前的 JVM 选项如下所示...

Djava.awt.headless=true
 -Xms512m
 -Xmx512m
 -Xmn128m
 -XX:MaxPermSize=128m
 -XX:+HeapDumpOnOutOfMemoryError
 -XX:+UseParNewGC
 -XX:+UseConcMarkSweepGC
 -XX:BiasedLockingStartupDelay=0
 -XX:+DoEscapeAnalysis
 -XX:+UseBiasedLocking
 -XX:+EliminateLocks
 -XX:+CMSParallelRemarkEnabled
 -verbose:gc
 -XX:+PrintGCTimeStamps
 -XX:+PrintGCDetails
 -XX:+PrintHeapAtGC
 -Xloggc:gc.log
 -XX:+CMSClassUnloadingEnabled
 -XX:+CMSPermGenPrecleaningEnabled
 -XX:CMSInitiatingOccupancyFraction=50
 -XX:ReservedCodeCacheSize=64m
 -Dnetworkaddress.cache.ttl=30
 -Xss128k

似乎并发-可中止-预清理永远不会有机会运行。我通读了 https://blogs.oracle.com/jonthecollector/entry/did_you_know 其中有一个关于启用CMSScavengeBeforeRemark的建议,但暂停的副作用似乎并不理想。任何人都可以提供任何建议吗?

我也想知道是否有人有很好的参考来浏览CMS GC日志,特别是这行:

[1 CMS-remark: 16015K(393216K)] 71979K(511232K), 0.0746640 secs]

不清楚这些数字指的是哪些内存区域。编辑找到指向此 http://www.sun.com/bigadmin/content/submitted/cms_gc_logs.jsp 的链接


答案 1

[次数:用户=0.00 sys=0.01,实数=5.09秒]

我会尝试调查为什么在5秒内既没有得到用户也没有系统CPU时间。CMS-concurrent-abortable-preclean-start

我的建议是从“干净”的JVM CMS启动标志开始,例如

-Djava.awt.headless=true
-Xms512m
-Xmx512m
-Xmn128m
-Xss128k
-XX:MaxPermSize=128m
-XX:+UseConcMarkSweepGC
-XX:+HeapDumpOnOutOfMemoryError
-Xloggc:gc.log
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-XX:+PrintHeapAtGC

然后检查问题是否再现,并一次调整一个参数。


答案 2

正如有人已经提到的那样,第一步是增加CMSInitiatingOccupancyFraction。

作为第二步,我会使用旗帜,并确保没有从年轻一代到老一代的过早晋升。这将导致从老到小的参考,这可能导致更长的可中止的预清洁阶段。如果有这样的过早提升,试着调整伊甸园和生存空间之间的比例。-XX:-PrintTenuringDistribution