为什么在这里发生CMS（并发模式故障）？ [英] Why CMS(concurrent mode failure) happened here?

问题描述

 操作系统：Red Hat Linux 4.8 
 
 CPU信息：Intel（R）Xeon®CPU 5160 @ 3.00GHz X 16 
 
 JDK版本：1.5.0_16
 
 JVM参数：
 -server 
 -Xmx1024m 
 -Xms1024m 
 -XX：NewSize = 256m 
 -XX：MaxNewSize = 256m 
 -XX：PermSize = 128m 
 -XX：MaxPermSize = 128m 
 -XX：SurvivorRatio = 8 
 -XX：+ PrintGCDetails 
 -XX：+ PrintGCTimeStamp 
 -XX：+ UseConcMarkSweepGC 
 -XX：+ UseCMSCompactAtFullCollection 
 -XX：CMSFullGCsBeforeCompaction = 5 
 -XX：CMSInitiatingOccupancyFraction = 60 
 -XX：CMSMaxAbortablePrecleanTime = 5 
 -XX：+ CMSPermGenSweepingEnabled 
 -XX：+ CMSClassUnloadingEnabled 
 -XX：MaxGCPauseMillis = 1500 
 
 JVM GC日志：
 
 945188.489：[GC 945188.489：[ParNew：224543K-> 14968K（235968K），0.0506680 secs] 552200K-> 344514K（1022400K），0.0507700 secs] 
 
 945242.102：[GC 945242.102 ：[ParNew：224760K-> 15374K（235968K），0.0632410secs] 554306K-> 346710K（1022400K），0.0633450 se cs] 
 
 945270.397：[GC 945270.402：[ParNew：225163K-> 225163K（235968K），0.0000230 secs] 945270.402：[CMS（并发模式失败）[卸载类sun.reflect.GeneratedSerializationConstructorAccessor70] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor58] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor38] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor62] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor54 ] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor74] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor53] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor73] 
 [卸载类sun.reflect .GeneratedSerializationConstructorAccessor64] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor39] 
 [卸载类sun.reflect.GeneratedSerializationConstruct 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor51] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor42] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor48] 
 [卸载类sun。 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor52] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor57] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor61] 
 [卸载类
 [正在卸载类sun.reflect.GeneratedSerializationConstructorAccessor55] 
 [卸载类sun.reflect.GeneratedSerializationConstructorAccessor40] 
 [卸载类sun 。[reflect.GeneratedSerializationConstructorAccessor65] 
：331336K-> 71676K（786432K），13.8120660secs] 556499K-> 71676K（1022400K），13.8122360secs] 
 
 945289.234：[GC945289.234：[ParNew ：209792K-> 2581K（235968K），0.0065240秒] 281468K-> 74257K（1022400K），0.0066160秒] 
 
 945324.703：[GC 945324.703：[ParNew：212373K-> 3829K（235968K） ，0.0081040秒] 284049K-> 75506K（1022400K），0.0082040秒] 
  

失败）发生在这里？

老一代似乎：331336K-> 71676K（786432K）

解决方案

根据定义的并发模式故障
$ b

消息并发模式失败
表示终身代
的并发
集合没有完成在终身
世代之前换句话说，新一代充斥得太快了，它已经流向了终身代，但是CMS不能满足这个要求。

在后台清除终身代。

在你的情况下，在945270.397

ParNew：225163K-> 225163K 235968K）显示Young已满，根本无法清除物体。

更新

类似的记录到你的账户在这里说明

这表明请求了一个ParNew集合
，但未尝试。
（原因是估计

CMS一代中没有足够的空间来推广
最残存的年轻一代
对象）。我们将此失败命名为全额
促销担保失败。因此，CMS的并发模式被中断，并调用完整的GC。

因此，当我看到它时，一个完整的GC对于225M的年轻对象以及331K的Tenured需要13秒，并将堆积降至71 M，但这是并发模式失败的结果。

建议

如果您真的创建了这么多旧对象，那么您可能需要一个更大的堆。

或者减少尝试从-60降低-XX：CMSInitiatingOccupancyFraction，但不认为这会使差异大大增加

Operation System: Red Hat Linux 4.8

CPU Info: Intel(R) Xeon(R) CPU 5160  @ 3.00GHz  X 16

JDK version: "1.5.0_16" 

JVM Parameter:
-server 
-Xmx1024m 
-Xms1024m 
-XX:NewSize=256m 
-XX:MaxNewSize=256m 
-XX:PermSize=128m 
-XX:MaxPermSize=128m 
-XX:SurvivorRatio=8 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+UseConcMarkSweepGC 
-XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction=5 
-XX:CMSInitiatingOccupancyFraction=60 
-XX:CMSMaxAbortablePrecleanTime=5 
-XX:+CMSPermGenSweepingEnabled 
-XX:+CMSClassUnloadingEnabled 
-XX:MaxGCPauseMillis=1500 

JVM GC Log:

945188.489: [GC 945188.489: [ParNew: 224543K->14968K(235968K), 0.0506680 secs] 552200K->344514K(1022400K), 0.0507700 secs] 

945242.102: [GC 945242.102: [ParNew: 224760K->15374K(235968K), 0.0632410 secs] 554306K->346710K(1022400K), 0.0633450 secs] 

945270.397: [GC 945270.402: [ParNew: 225163K->225163K(235968K), 0.0000230 secs]945270.402: [CMS (concurrent mode failure)[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor70] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor58] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor38] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor62] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor54] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor74] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor53] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor73] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor64] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor39] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor59] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor51] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor42] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor48] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor76] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor52] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor57] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor61] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor56] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor55] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor63] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor60] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor40] 
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor65] 
: 331336K->71676K(786432K), 13.8120660 secs] 556499K->71676K(1022400K), 13.8122360 secs] 

945289.234: [GC 945289.234: [ParNew: 209792K->2581K(235968K), 0.0065240 secs] 281468K->74257K(1022400K), 0.0066160 secs] 

945324.703: [GC 945324.703: [ParNew: 212373K->3829K(235968K), 0.0081040 secs] 284049K->75506K(1022400K), 0.0082040 secs] 

Why CMS(concurrent mode failure) happened here?

The old generation seems : 331336K->71676K(786432K)

解决方案

Concurrent Mode Failure as defined

The message "concurrent mode failure" signifies that the concurrent collection of the tenured generation did not finish before the tenured generation became full.

In other words, the new generation is filling up too fast, it is overflowing to tenured generation but the CMS could not clear out the tenured generation in the background.

In your case, at 945270.397

ParNew: 225163K->225163K(235968K) shows the Young was full and could not clear objects at all.

Update

A similar log to yours is explained here says

This shows that a ParNew collection was requested, but was not attempted. (The reason is that it was estimated that there was not enough space in the CMS generation to promote the worst-case surviving young generation objects.) We name this failure a "full promotion guarantee failure". As a result, the concurrent mode of CMS is interrupted and a full GC is invoked.

So as I see it, a full GC on the young objects of 225M as well as the Tenured of 331K takes 13 seconds and gets the heap down to 71 M, but this has been a result of the concurrent mode failure

Suggestion

If you are really creating so many old objects, then you probably need a bigger heap.

Or reduce try reducing the -XX:CMSInitiatingOccupancyFraction from 60 but dont think that will make much of a diff

这篇关于为什么在这里发生CMS（并发模式故障）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！