Ненужный полный GC с сборщиком мусора G1 в Java 8?

Question

Мы заметили случайные полные GC с сборщиком мусора G1 с переполнением параллельной метки. Однажды существует параллельный-mark-reset-for-overflow, это переполнение будет продолжаться в следующих фазах параллельных меток. В конце концов, это приводит к полному GC, поскольку совпадающий знак больше не работает.

У нас есть четыре машины, на которых работает одно и то же приложение на базе Apache Storm с тем же трафиком данных. Только одна из машин имеет этот опыт один раз в неделю.

Является ли это связанно с ошибкой: «G1 не расширяется маркировкой стеки при переполнении стеки метки происходит во время одновременной маркировки» https://bugs.openjdk.java.net/browse/JDK-8065402

Согласно предложению от указанной выше страницы, мы удвоили параллельные потоки метки от 4 до 8 и размер нашей кучи от 8 до 16 ГБ. Тем не менее, полный GC все еще происходит, и единственная разница в том, что события задерживаются.

Любые другие предложения?

Вот журнал GC:

Java HotSpot(TM) 64-Bit Server VM (25.65-b01) for linux-amd64 JRE(1.8.0_65b17), 
built on Oct 6 2015 17:16:12 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8) 
Memory: 4k page, physical 529167668k(69283408k free), swap 33554424k(33552380k free) 
CommandLine flags: -XX:ConcGCThreads=8 -XX:G1ReservePercent=20 -XX:GCLogFileSize=104857600 
-XX:InitialHeapSize=17179869184 -XX:InitiatingHeapOccupancyPercent=45 -XX:MaxGCPauseMillis=100 
-XX:MaxHeapSize=17179869184 -XX:NumberOfGCLogFiles=10 -XX:ParallelGCThreads=30 
-XX:+PrintAdaptiveSizePolicy -XX:PrintFLSStatistics=2 -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime 
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC 
-XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseGCLogFileRotation 
... 
... 
2016-04-13T22:06:37.254-0400: 19839.175: [GC concurrent-root-region-scan-start] 
2016-04-13T22:06:37.313-0400: 19839.234: [GC concurrent-root-region-scan-end, 0.0592966 secs] 
2016-04-13T22:06:37.313-0400: 19839.234: [GC concurrent-mark-start] 
2016-04-13T22:06:38.569-0400: 19840.490: [GC concurrent-mark-reset-for-overflow] 
... 
2016-04-13T22:06:42.810-0400: 19844.731: [GC concurrent-mark-reset-for-overflow] 
... 
2016-04-13T22:11:19.253-0400: 20121.175: [GC concurrent-mark-reset-for-overflow] 
... 
... 
... 
2016-04-14T01:58:17.254-0400: 33739.176: [GC concurrent-mark-reset-for-overflow] 
... 
2016-04-14T01:58:36.957-0400: 33758.878: [Full GC (Allocation Failure) 

Answer 1

От оракула g1_gc блога:

GC concurrent-mark-reset-for-overflow: Это указывает на то, что глобальная маркировка стопка была наполнилась и не было переполнения стека. Параллельная маркировка обнаружила это переполнение и вынуждена была перезапустить структуры данных, чтобы снова начать разметку

Таким образом, увеличение -XX:MarkStackSize - это быстрая победа.

Несколько наблюдений из ваших параметров VM:

1. Система G1 GC представляет собой адаптивный сборщик мусора с невыполнением, которые позволяют ему эффективно работать без изменений. Кратко посмотрите документацию оракула page на G1GC
2. Параметры ввода: -XX:MaxGCPauseMillis, -XX:G1HeapRegionSize,-XX:ParallelGCThreads=n, -XX:ConcGCThreads=n Оставьте все остальное значениям по умолчанию.
3. Если размер вашей кучи составляет 16 ГБ, идеальным размером области должен быть 8 MB. Убедитесь, что вы поддерживаете 2048 регионов.
4. Повторите попытку цели времени паузы. -XX:MaxGCPauseMillis. Если 200ms нереально для кучи 16 ГБ, установите это значение как должным образом.

5. Страница официальной документации рекомендует установить XX:ParallelGCThreads=n, -XX:ConcGCThreads=n в зависимости от количества ядер в вашей машине.

   -XX:ParallelGCThreads=n: Устанавливает значение рабочих потоков STW. Устанавливает значение n в число логических процессоров. Значение n совпадает с количеством логических процессоров до значения 8.

   -XX:ConcGCThreads=n: Устанавливает количество параллельных разметки. Устанавливает n примерно на 1/4 числа параллельных потоков сбора мусора (ParallelGCThreads).

6. Revisit -XX:InitialHeapSize=17179869184 -XX:InitiatingHeapOccupancyPercent=45 -XX:G1ReservePercent=20 параметров. Оставьте их значениями по умолчанию, если у вас нет необходимости изменять их.

Посетите эту страницу для лучшего понимания G1GC журналов.