我正在使用Java CMS垃圾收集器,并尝试理解类似以下的日志行:
根据阅读http://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs,CMS将在各种情况下进行完整的垃圾回收(例如,如果"在scavenge尝试中升级失败"),但根据该博客,它会记录完整GC的原因。
相反,我看到了临时的完整GC。它肯定是CMS,因为有其他CMS日志条目。
是否有理由进行完整的GC,但不记录原因?
编辑: 抱歉,有多个Java安装程序(我继承了这个设置)。实际上它使用jdk1.6.0_27。
编辑 不幸的是,JVM参数被包含在配置文件中(这是在Tomcat上运行的商业应用程序),但我非常确定它们是:
22609.787: [GC 22609.788: [ParNew: 1116101K->79200K(1310720K), 0.2369136 secs] 1551730K->516431K(6029312K), 0.2379422 secs] [Times: user=1.68 sys=0.02, real=0.24 secs]
22610.741: [Full GC 22610.741: [CMS: 437230K->278442K(4718592K), 14.8596841 secs] 573355K->278442K(6029312K), [CMS Perm : 241468K->236967K(241856K)], 14.8694544 secs] [Times: user=14.80 sys=0.13, real=14.87 secs]
22635.415: [GC 22635.416: [ParNew: 1048576K->43613K(1310720K), 0.0904065 secs] 1327018K->322055K(6029312K), 0.0914701 secs] [Times: user=0.45 sys=0.00, real=0.09 secs]
根据阅读http://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs,CMS将在各种情况下进行完整的垃圾回收(例如,如果"在scavenge尝试中升级失败"),但根据该博客,它会记录完整GC的原因。
相反,我看到了临时的完整GC。它肯定是CMS,因为有其他CMS日志条目。
是否有理由进行完整的GC,但不记录原因?
编辑: 抱歉,有多个Java安装程序(我继承了这个设置)。实际上它使用jdk1.6.0_27。
编辑 不幸的是,JVM参数被包含在配置文件中(这是在Tomcat上运行的商业应用程序),但我非常确定它们是:
min.heapsize=6144m
max.heapsize=6144m
-Xss=512k
-XX:MaxPermSize=512m
-XX:NewSize=1536m
-XX:MaxNewSize=1536m
-XX:SurvivorRatio=4
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+UseTLAB
-XX:+UseCompressedOops
-XX:+PrintVMOptions
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCTaskTimeStamps
-XX:+PrintCommandLineFlags
-XX:+PrintGCApplicationStoppedTime
-XX:StackShadowPages=20
-XX:+DisableExplicitGC