Коллекция мусоровозов мульчирования содержит несколько полных GC

Question

Мы работаем с граалями, и мы замечаем, что для очистки пространства пермгенов требуется несколько полных сборков мусора.

2013-06-06T16:11:27.016+0000: 32582.145: [Full GC 32582.145: [CMS2013-06-06T16:11:45.404+0000:  32600.532: [CMS-concurrent-mark: 21.403/86.063 secs] [Times: user=48.44 sys=0.63, real=86.07 secs] 
(concurrent mode failure): 7585874K->7290466K(10145024K), 57.9230770 secs] 7866094K->7290466K(10451712K), [CMS Perm : 261766K->261702K(262144K)] icms_dc=30 , 57.9232150 secs] [Times: user=57.97 sys=0.00, real=57.93 secs] 
2013-06-06T16:12:25.183+0000: 32640.311: [GC [1 CMS-initial-mark: 7290466K(10145024K)] 7385976K(10451712K), 0.0880890 secs] [Times: user=0.09 sys=0.00, real=0.08 secs] 
2013-06-06T16:12:25.271+0000: 32640.400: [CMS-concurrent-mark-start] 
2013-06-06T16:12:25.427+0000: 32640.555: [GC 32640.556: [ParNew: 272640K->10006K(306688K), 0.0622620 secs] 7563106K->7300472K(10451712K) icms_dc=30 , 0.0624140 secs] [Times: user=0.24 sys=0.00, real=0.06 secs] 
2013-06-06T16:12:25.734+0000: 32640.863: [GC 32640.863: [ParNew: 282646K->13476K(306688K), 0.0648770 secs] 7573112K->7303942K(10451712K) icms_dc=30 , 0.0650170 secs] [Times: user=0.26 sys=0.00, real=0.07 secs] 
2013-06-06T16:12:26.013+0000: 32641.142: [GC 32641.142: [ParNew: 286116K->11277K(306688K), 0.0607460 secs] 7576582K->7301743K(10451712K) icms_dc=30 , 0.0608870 secs] [Times: user=0.25 sys=0.00, real=0.06 secs] 
2013-06-06T16:12:32.449+0000: 32647.577: [GC 32647.577: [ParNew: 283917K->17560K(306688K), 0.0672260 secs] 7574383K->7308026K(10451712K) icms_dc=30 , 0.0673710 secs] [Times: user=0.27 sys=0.00, real=0.07 secs] 
2013-06-06T16:12:33.107+0000: 32648.236: [GC 32648.236: [ParNew: 290200K->22523K(306688K), 0.0686820 secs] 7580666K->7312989K(10451712K) icms_dc=30 , 0.0688200 secs] [Times: user=0.28 sys=0.00, real=0.07 secs] 
2013-06-06T16:12:33.845+0000: 32648.974: [Full GC 32648.974: [CMS2013-06-06T16:12:52.516+0000: 32667.645: [CMS-concurrent-mark: 21.346/27.245 secs] [Times: user=27.55 sys=0.14, real=27.25 secs] 
(concurrent mode failure): 7290466K->7293289K(10145024K), 57.7092090 secs] 7523492K->7293289K(10451712K), [CMS Perm : 262143K->262143K(262144K)] icms_dc=30 , 57.7093560 secs] [Times: user=57.76 sys=0.00, real=57.71 secs] 
2013-06-06T16:13:31.557+0000: 32706.686: [Full GC 32706.686: [CMS: 7293289K->6960613K(10145024K), 37.1325250 secs] 7293289K->6960613K(10451712K), [CMS Perm : 262143K->91949K(262144K)] icms_dc=30 , 37.1326670 secs] [Times: user=37.19 sys=0.00, real=37.14 secs] 

Первый собирает только 64K, то второй не собирает ничего, а затем, наконец, третий способен собирать 170194K

JAVA_OPTIONS: 
-XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenSweepingEnabled 
-XX:+UseConcMarkSweepGC 
-XX:MaxPermSize=256m 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDateStamps 
-verbose:gc,sizes 
-XX:+UseConcMarkSweepGC 
-XX:CMSInitiatingOccupancyFraction=80 
-XX:+DisableExplicitGC 
-XX:+CMSIncrementalMode 
-XX:+UseParNewGC 
-Xms10g -Xmx10g 

Кроме того, есть в любом случае, чтобы сказать получить сборщик мусора сделать инкрементный развертка пространства пермгенов? Мы видим, что во время полных коллекций сокращается число переводов.

Answer 1

Один из способов определения того, что собирается в последней коллекции FullGC, - гистограммы класса печати до/после Full GC: -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC.

Таким образом вы можете сравнить гистограммы из всех коллекций и определить, какие классы собраны в последнем.

К вашему второму вопросу, рассматривающему PermGen, обычный совет - определить достаточный размер PermGen для вашего приложения/рабочей нагрузки и придерживаться этого. Вам нужно исследовать, почему в PermGen размещено так много объектов.

Answer 2

Позвольте мне сделать разъяснение относительно параллельного Mark Sweep и алгоритма инкрементного режима. Инкрементный режим CMS был введен, чтобы избежать голодания процессора на одноядерных серверах, в то время как фоновый GC работает. Использование инкрементной CMS не рекомендуется.

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

-XX:+CMSPermGenSweepingEnabled является устаревшим и синоним -XX:+CMSClassUnloadingEnabled

пошагового режим несколько hiders обнаружения мертвого объекта и моя проблема.

Кроме того, если какой-либо из классов (для разгрузки) имеет finilazer, это также может объяснить две коллекции (JVM не может выгружать отдельные классы, весь загрузчик классов разгружается, поэтому любой из его классов может предотвратить сбор).

Я бы посоветовал правильно настроить кучу и perm gen и настроить CMS на более агрессивную, если вы хотите сохранить этот уровень использования кучи. В my blog вы можете найти несколько советов по настройке CMS.

Если, однако, вы запускаете время, то активно производят и отказываются от загрузки загрузчиков классов, возможно, недостаточно.

Я столкнулся с аналогичными проблемами с автоматическими тестами (каждый тест загружал одни и те же классы в выделенный загрузчик классов для изоляции). Тест был, как правило, нестабильным, бросая OOME в perm gen. Решение заключалось в том, чтобы заставить JVM очистить perm gen, загрязнив его данными мусора (here is snippet of code). Это вызывало Full GC, хотя, вероятно, не то, что вы хотели бы видеть.

BTW Существует также флаг -XX:CMSClassUnloadingMaxInterval=N, который позволяет JVM собирать Пермский ген только для каждой коллекции Nth. Но это не ваш случай, потому что perm gen полна.