低暂停收集器-并发模式失败

Question

我们在Prod中遇到了一个应用程序的问题。

VM配置如下

-xx:maxpermsize=300m-xms2560m-xmx2560m-xloggc:/app/log/gc-admin-20120619-123754.log-verbose：gc-xx:+printgctimestamps-xx:+printgcdetails-xx:+useconcmarksweepgc-xx:cmsinitiatingoccupancyfraction=80-xx:+disableexplicitgc-xx:cmsmaxabortableprecleantime=8000

我错过了两个将被应用的选项：xx：permsize-应该与MaxPermSize（推荐）相同，仅当使用CMSInitiatingOccupancyFraction时才使用usecmsinitiatingoccupancy，否则您指定的值不适用！！

然而，随着这些改变在pipleline，我不是那么有信心，它将解决我的问题。

我看到并发模式失败，但当一个失败发生，停止世界集合需要一个永恒。现在我有点不明白为什么！！

这是一些样品

168427.476:[GC[1 CMS-initial-mark:2135988k(2578880k)]2141041k(2617216k)，3.1029210秒][times:user=0.02 SYS=0.01，real=3.10秒]168430.596:[CMS-concurrent-mark-start]168441.309:[GC168441.309:[Parnew:36520k->36520k(38336k)，0.0000210秒]168441.309:[CMS168747.453:[CMS-concurrent-mark:309.313/316.857秒][times:user=5.75

令我担心的是整个STW集合的定时766.92秒，但只有“user=3.87sys=5.06”的CPU时间，所以在其余时间这里发生了什么？这是我困惑的地方，我无法想象停止应用程序中的所有线程需要这么长的时间！！可能是痛打？？

169545.325：[GC[1 CMS-初始标记：2141069K(2578880K)]2166025K(2617216K)，0.0530140秒][次数：USER=0.05 SYS=0.00，实际=0.06秒]169545.379:[CMS-concurrent-mark-start]169558.635:[CMS-并发标记：10.407/13.256秒][倍：USER=7.58 SYS=0.53，real=13.25秒]169558.635:[CMS-concurrent-preclean-start]169558.684:[CMS-Concurrent-Preclean:0.048/0.048秒][times:user=0.01 sys=0.00，real=0.05秒]169558.684:[CMS-concurrent-abortable-preclean-start]169560.544:[GC 169560.544:[Parnew169560.605:[CMS-Concurrent-Abortable-Preclean:0.210/1.921秒][times:user=0.93 sys=0.05,real=1.92秒]169560.846:[GC[YG占用：1906 K（38336 K）]169560.846:[重新扫描（并行），0.0046910秒

这个没有问题

252247.318:[GC[1 CMS-Initial-Mark:2069401K(2578880K)]2075094K(2617216K)，1.5311840秒][times:user=0.01 SYS=0.00，real=1.53秒]252248.849:[CMS-concurrent-mark-start]252350.336:[GC252350.336:[Parnew:20984K->4222K(38336K)，12.2251190秒]252362.561:[CMS252520.780:[CMS-Concurrent-Mark:161.376/271.922秒][times:user=12.56 SYS=1.72,

然后是另一个巨大的“时间:user=4.23sys=2.99，real=419.39秒”。CPU时间较少“user=4.23 sys=2.99”，但总体时间为“419.39”。是什么原因导致虚拟机挂起这么长时间？？最好是在10secs以下的STW收集器中收集2.5g！！

我将降低CMSInitiatingOccupancyFraction的阈值，但我不认为这样的集合时间会有帮助！！有些收藏运行顺利，有些不顺利，但就像我说的，它的时机让我担心，当世界的一个句号发生。

我读过https://blogs.oracle.com/jonthecollector/entry/what_the_heck_s_a

我们使用的是JDK6。

以前有人经历过类似的事情吗？

Answer 1

正如您所观察到的，当并发模式失败时，返回到stop-the-world集合。我的理解是，这可以使用标记-扫描-紧凑收集器而不是更有效的复制收集器来完成。

这并不能完全解释为什么收集需要这么长时间。然而，虚拟机攻击是一个可信的理论，而且你的证据支持这一点...但是你需要得到一些虚拟机交换/分页速率的OS级测量值来确定。（如果JVM会导致混乱，那么在堆已满的情况下进行完全垃圾回收时，这种情况最有可能是最糟糕的。）

回到导致并发模式失败的原因,您链接到的博客说了最有可能发生的事情：

• 您的堆已满，或
• 对象分配率太高，或
• 对象分配率太可变，或
• 上述内容的某种组合。

建议的解决办法有：

• 增加堆大小。
• 减小CMSInitiatingOccupancyFraction值
• 增加CMSIncrementalSafetyFactor值