Непрерывные коллекции CMS, за которыми следует сбой параллельного режима

Журнал GC для моего Java-приложения указывает на непрерывную сборку CMS GC, за которой следует сбой в параллельном режиме, сбор данных Stop-the-World, который восстанавливает почти всю кучу.

Почему коллекции CMS не удаляют данные старого поколения? Почему требуется сбор данных о сбое в параллельном режиме?

Сборы CMS, подобные приведенному ниже, происходили непрерывно в течение нескольких дней, прежде чем сбой в параллельном режиме, наконец, вынудил сбор с остановкой мира, который освободил место. Обратите внимание, что коллекции CMS почти не восстанавливают место, в то время как коллекция после сбоя продвижения уменьшает размер старого поколения с 1,92 ГБ до 50,7 МБ.

Поддерживаются ли объекты старого поколения мертвыми, несобранными объектами в постоянном поколении, которые отбрасываются во время сбора STW? Должен ли я рассмотреть возможность использования ‑XX:+CMSClassUnloadingEnabled для решения этой проблемы?

Полная коллекция CMS в журнале GC:

2014-06-10T22:54:45.999-0700: 4999434.771: [GC [1 CMS-initial-mark: 1920327K(1926784K)] 2050302K(2080128K), 0.3369430 secs] [Times: user=0.34 sys=0.00, real=0.33 secs] 
2014-06-10T22:54:46.338-0700: 4999435.111: [CMS-concurrent-mark-start]
2014-06-10T22:54:50.543-0700: 4999439.315: [CMS-concurrent-mark: 4.204/4.204 secs] [Times: user=4.21 sys=0.08, real=4.20 secs] 
2014-06-10T22:54:50.543-0700: 4999439.315: [CMS-concurrent-preclean-start]
2014-06-10T22:54:50.573-0700: 4999439.345: [CMS-concurrent-preclean: 0.023/0.030 secs] [Times: user=0.02 sys=0.00, real=0.04 secs] 
2014-06-10T22:54:50.573-0700: 4999439.346: [CMS-concurrent-abortable-preclean-start]
2014-06-10T22:54:54.599-0700: 4999443.371: [GC2014-06-10T22:54:54.599-0700: 4999443.372:    [ParNew
Desired survivor size 8716288 bytes, new threshold 6 (max 6)
- age   1:    1410440 bytes,    1410440 total
- age   2:     181888 bytes,    1592328 total
- age   3:     117864 bytes,    1710192 total
- age   4:     136792 bytes,    1846984 total
- age   5:     161296 bytes,    2008280 total
- age   6:    2488416 bytes,    4496696 total
: 141989K->5449K(153344K), 0.1317090 secs] 2062317K->1925911K(2080128K), 0.1321970 secs]    [Times: user=0.23 sys=0.01, real=0.14 secs] 
 CMS: abort preclean due to time 2014-06-10T22:54:55.606-0700: 4999444.378: [CMS-concurrent-abortable-preclean: 2.600/5.033 secs] [Times: user=2.88 sys=0.08, real=5.03 secs] 
2014-06-10T22:54:55.611-0700: 4999444.384: [GC[YG occupancy: 10356 K (153344 K)]2014-06-10T22:54:55.612-0700: 4999444.384: [Rescan (parallel) , 0.1665620 secs]2014-06-10T22:54:55.778-0700: 4
999444.550: [weak refs processing, 0.0000440 secs]2014-06-10T22:54:55.778-0700: 4999444.551: [scrub string table, 0.0010220 secs] [1 CMS-remark: 1920462K(1926784K)] 1930818K(2080128K), 0.1678710 secs] [Times: user=0.28 sys=0.00, real=0.17 secs] 
2014-06-10T22:54:55.780-0700: 4999444.552: [CMS-concurrent-sweep-start]
2014-06-10T22:54:57.554-0700: 4999446.326: [CMS-concurrent-sweep: 1.775/1.775 secs]    [Times: user=1.82 sys=0.01, real=1.78 secs] 
2014-06-10T22:54:57.554-0700: 4999446.327: [CMS-concurrent-reset-start]
2014-06-10T22:54:57.564-0700: 4999446.336: [CMS-concurrent-reset: 0.009/0.009 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]

Журнал GC сбоя в параллельном режиме:

2014-06-10T22:56:18.793-0700: 4999527.565: [GC [1 CMS-initial-mark: 1920286K(1926784K)] 2051254K(2080128K), 0.3388330 secs] [Times: user=0.33 sys=0.00, real=0.33 secs] 
2014-06-10T22:56:19.132-0700: 4999527.904: [CMS-concurrent-mark-start]
2014-06-10T22:56:23.112-0700: 4999531.884: [CMS-concurrent-mark: 3.976/3.980 secs] [Times: user=4.07 sys=0.04, real=3.99 secs] 
2014-06-10T22:56:23.112-0700: 4999531.885: [CMS-concurrent-preclean-start]
2014-06-10T22:56:23.141-0700: 4999531.914: [CMS-concurrent-preclean: 0.022/0.029 secs] [Times: user=0.01 sys=0.01, real=0.03 secs] 
2014-06-10T22:56:23.141-0700: 4999531.914: [CMS-concurrent-abortable-preclean-start]
2014-06-10T22:56:26.242-0700: 4999535.014: [GC2014-06-10T22:56:26.242-0700: 4999535.014: [ParNew2014-06-10T22:56:26.256-0700: 4999535.028: [CMS-concurrent-abortable-preclean: 1.948/3.114 secs] [Times: user=1.93 sys=0.12, real=3.11 secs] 
 (promotion failed)
Desired survivor size 8716288 bytes, new threshold 6 (max 6)
- age   1:    1036320 bytes,    1036320 total
- age   2:     825248 bytes,    1861568 total
- age   3:     119024 bytes,    1980592 total
- age   4:     113784 bytes,    2094376 total
- age   5:     129024 bytes,    2223400 total
- age   6:     154976 bytes,    2378376 total
: 141769K->140729K(153344K), 0.3807730 secs]2014-06-10T22:56:26.623-0700: 4999535.395: [CMS
 (concurrent mode failure): 1920816K->50773K(1926784K), 28.3938140 secs] 2062055K->50773K(2080128K), [CMS Perm : 48657K->41071K(262144K)], 28.7750370 secs] [Times: user=1.65 sys=0.03, real=28.78 secs]

Java-версия:

$ /usr/java/jdk1.7.0_51/bin/java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

Опции JVM:

-Xms2048m
-Xmx2048m
-XX:PermSize=256m
-XX:MaxPermSize=256m
-XX:+UseConcMarkSweepGC
-XX:+PrintClassHistogram
-XX:+DisableExplicitGC
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintTenuringDistribution
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=<logs dir>
-Xloggc:<log path>

java jvm garbage-collection heap-memory concurrent-mark-sweep
person Elliot    schedule 03.07.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Сборка мусора собирает мертвые объекты/нулевую ссылку. Здесь используется политика низкой паузы. Ниже приведены вещи, которые могут произойти в среде приложения.

Причина 1:

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

Причина 2:

Если заданное значение Xmx является оптимальным для запуска приложения, то существует вероятность утечки памяти в среде приложения, что приводит к тому, что куча Java занимает объекты, которые не могут быть очищены сборщиком мусора.

Утечку памяти можно определить следующими способами. Добавьте аргумент -verbose:gc jvm и соберите журналы GC. После сбора журналов загрузите журнал gc в инструмент ниже http://www.ibm.com/developerworks/java/jdk/tools/gcmv/ Дополнительную информацию об утечке памяти см. ниже. http://www.oracle.com/technetwork/java/javase/memleaks-137499.html

person Mohan Raj    schedule 21.04.2015