Почему CMS (сбой одновременного режима) произошел здесь? - PullRequest
Новая
       59

Почему CMS (сбой одновременного режима) произошел здесь?

5 голосов
/ 14 сентября 2010 
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]

Почему CMS (сбой параллельного режима) произошел здесь?

Старое поколение выглядит следующим образом: 331336K-> 71676K (786432K)

1 Ответ

10 голосов
/ 14 сентября 2010

Сбой одновременного режима в соответствии с определением

Сообщение «Сбой одновременного режима» означает, что одновременный сбор данных с постоянным поколением не завершился до того, как сгенерированное поколение стало полным.

Другими словами, новое поколение заполняется слишком быстро, оно переполняется на постоянное поколение, но CMS не может очистить постоянное поколение в фоновом режиме.

В вашем случае на 945270.397

ParNew: 225163K->225163K(235968K) показано, что Юнг был полон и не мог очистить объекты вообще.

Обновление

Объясняется аналогичный ваш журнал здесь говорится

Это показывает, что коллекция ParNew былапросили, но не пытались.(Причина в том, что было подсчитано, что в поколении CMS не хватило места для продвижения наихудших объектов выжившего молодого поколения.) Мы называем этот отказ «полным провалом гарантии продвижения».В результате одновременный режим CMS прерывается и вызывается полный сборщик мусора.

Итак, на мой взгляд, полный сборщик мусора для молодых объектов размером 225 м, а также для Tenured из 331 тыс. Кадров, занимает13 секунд и уменьшает кучу до 71 М, но это было результатом сбоя одновременного режима

Предложение

Если вы действительно создаете так много старых объектовтогда вам, вероятно, нужна большая куча.

Или уменьшите, попробуйте уменьшить -XX: CMSInitiatingOccupancyFraction с 60, но не думайте, что это сильно изменится

...