Question

我正在运行一个使用CMS作为终身收藏家的Java服务器。在负载测试下运行，我看到每个1s的年轻集合和大约每5米的终身（并发）。这很好。

当我以大约1/2容量的实际流量运行时，我会得到大约每4秒的年轻收藏品并且每隔7米就会终身（！平行，停止世界！）。为什么JVM决定使用完全停止收集而不是使用CMS收集器？

从gc.log中可以看到＆＃34; Full GC＆＃34;正在运行并接管3s完成。这里没有并发模式失败。什么都没有明确要求收集。

1350.596: [GC 1350.596: [ParNew
Desired survivor size 119275520 bytes, new threshold 3 (max 3)
- age   1:   34779376 bytes,   34779376 total
- age   2:   17072392 bytes,   51851768 total
- age   3:   24120992 bytes,   75972760 total
: 1765625K->116452K(1864192K), 0.1560370 secs] 3887120K->2277489K(5009920K), 0.1561920 secs] [Times: user=0.40 sys=0.04, real=0.16 secs] 
1355.106: [GC 1355.107: [ParNew
Desired survivor size 119275520 bytes, new threshold 3 (max 3)
- age   1:   44862680 bytes,   44862680 total
- age   2:   20363280 bytes,   65225960 total
- age   3:   16908840 bytes,   82134800 total
: 1747684K->123571K(1864192K), 0.1068880 secs] 3908721K->2307790K(5009920K), 0.1070130 secs] [Times: user=0.29 sys=0.04, real=0.11 secs] 
1356.106: [Full GC 1356.106: [CMS: 2184218K->1268401K(3145728K), 3.0678070 secs] 2682861K->1268401K(5009920K), [CMS Perm : 145090K->145060K(262144K)], 3.0679600 secs] [Times: user=3.05 sys=0.02, real=3.07 secs] 
1361.375: [GC 1361.375: [ParNew
Desired survivor size 119275520 bytes, new threshold 3 (max 3)
- age   1:   33708472 bytes,   33708472 total
: 1631232K->84465K(1864192K), 0.0189890 secs] 2899633K->1352866K(5009920K), 0.0191530 secs] [Times: user=0.19 sys=0.00, real=0.02 secs] 
1365.587: [GC 1365.587: [ParNew
Desired survivor size 119275520 bytes, new threshold 3 (max 3)
- age   1:   33475320 bytes,   33475320 total
- age   2:   22698536 bytes,   56173856 total
: 1715697K->67421K(1864192K), 0.0229540 secs] 2984098K->1335822K(5009920K), 0.0231240 secs] [Times: user=0.25 sys=0.00, real=0.03 secs]

以下是JVM标志：

-server -Xss256K -Xms5120M -Xmx5120M -XX:NewSize=2048M -XX:MaxNewSize=2048M
-XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=80
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSFullGCsBeforeCompaction=1
-XX:SoftRefLRUPolicyMSPerMB=73 -verbose:gc -XX:+PrintGCDetails
-XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -Xloggc:logs/gc.log
-XX:MaxPermSize=256m -XX:PermSize=256m -XX:MaxTenuringThreshold=3

Answer 1

如果你的幸存者空间不够大，它可以触发一个完整的GC。（似乎是抱怨他的幸存者比例）

要么你需要降低你的幸存者比率，要么更好的解决方案可能是增加你的NewSize，以便减少从伊甸园空间中存活的对象。我有一个6 GB的伊甸园空间;）

Answer 2

我似乎记得去年在调整大堆以避免完整GC时看到了类似的现象。我想你可能想减少伊甸园的大小。与终身一代相比，这相当大。

我认为可能会发生的事情是，你的1/2速度流量会使你的伊甸园更多地“老化”，而不是全速（他们没有幸存）。这意味着更多需要立即转为终身。如果它在那时不合适，它可能会触发一个完整的GC来腾出空间。

此处参考我们现在使用的6GB到24GB堆：

-XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:+UseCompressedOops
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC  
-XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled  
-XX:+CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=68
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:logs/gc.log

它与你的相似。使用所有比率的好处是，您可以轻松地更改堆大小，并（通常）适当地缩放。另外需要注意的是，-XX:+UseCompressedOops通过将64位寻址减少到32位（最多只能工作32GB），通常可以减少40％的内存。

Java CMS被忽略并获得完整的GC

2 个答案: