如下所示,在一切按预期工作的过程中,世界各地的GC操作耗时+60秒。它可以被确定为一个停止世界的整个时间,因为(兵马俑)客户掉线,抱怨它(兵马俑服务器)在那段时间没有响应。
这是年轻/次要GC吗?如果是的话,是不是因为年轻一代的饥饿(伊甸园+幸存者?)。
只有109333(KB)是免费的吗?
我将开始绘制不同的内存容器图表,还有其他建议可以做些什么来进一步诊断这些问题?
date, startMem=24589884, endMem=24478495, reclaimed=111389, timeTaken=0.211244 (1172274.139: [GC 24589884K->24478495K(29343104K), 0.2112440 secs])
date, startMem=24614815, endMem=24505482, reclaimed=109333, timeTaken=61.301987 (1172276.518: [GC 24614815K->24505482K(29343104K), 61.3019860 secs])
date, startMem=24641802, endMem=24529546, reclaimed=112256, timeTaken=2.68437 (1172348.921: [GC 24641802K->24529546K(29343104K), 2.6843700 secs])
Sun JVM是1.6,使用以下配置:
-Xms28672m -Xmx28672m -XX:+ UseConcMarkSweepGC -XX:+ PrintGCTimeStamps -XX:+ PrintGC
Sane配置调整以进一步调试GC:
'-XX:+PrintGCDateStamps' Print date stamps instead of relative timestamps
'-XX:+PrintGCDetails' Will show what cpu went for (user, kern), gc algorithm used
'-XX:+PrintHeapAtGC' will show all of the heaps memory containers and their usage
'-Xloggc:/path/to/dedicated.log' log to specific file
答案 0 :(得分:1)
-XX:+UseConcMarkSweepGC
启用并发收集
所花费的总时间是停止世界阶段(JVM阻止)和并发阶段(JVM执行用户代码)的总和。
您应该启用详细的GC日志记录以进一步调查,因为您没有关于+60秒中有多少阻止JVM的信息。