Полный G C (инициированный осмотр кучи G C) - PullRequest
Новая
       37

Полный G C (инициированный осмотр кучи G C)

2 голосов
/ 18 января 2020

Я изо всех сил пытаюсь выловить "Full G C" на нашей производственной JVM. Каждый день около полуночи STW происходит без видимой причины, довольно смертельно для 10-11 се c. Вот g c log: 

Java HotSpot(TM) 64-Bit Server VM (25.131-b11) for windows-amd64 JRE (1.8.0_131-b11), built on Mar 15 2017 01:23:53 by "java_re" with MS VC++ 10.0 (VS2010)
Memory: 4k page, physical 16584284k(13074876k free), swap 23137624k(18439472k free)
CommandLine flags: -XX:GCLogFileSize=1024000 -XX:InitialHeapSize=11811160064 -XX:+ManagementServer -XX:MaxHeapSize=11811160064 -XX:NumberOfGCLogFiles=10 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseGCLogFileRotation -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC 
...
2020-01-17T00:00:04.411+0200: 113734.053: [GC (Heap Inspection Initiated GC) [PSYoungGen: 522474K->146371K(3387904K)] 6946079K->6573263K(11077632K), 0.1786961 secs] [Times: user=0.67 sys=0.02, real=0.18 secs] 
2020-01-17T00:00:04.592+0200: 113734.233: [Full GC (Heap Inspection Initiated GC) [PSYoungGen: 146371K->0K(3387904K)] [ParOldGen: 6426892K->3217828K(7689728K)] 6573263K->3217828K(11077632K), [Metaspace: 81937K->81809K(1126400K)], 11.4447857 secs] [Times: user=44.06 sys=0.20, real=11.44 secs]

Что на самом деле означает "Инициированный контроль кучи G C" ? Кто инициирует эту проверку и почему? Мне не удалось найти какую-либо значимую информацию о нем, кроме как вызванную некоторыми инструментами, такими как jmap, jm c .., которые мы не используем.

Любая подсказка или направление высоко ценится.

Ответы [ 2 ]

2 голосов
/ 19 января 2020

Агент JVM может также запустить проверку кучи . Чтобы узнать жизнеспособность Объектов в текущий момент, вам нужно вызвать Full GC вызов. Я предполагаю, что в случаях Shenandoah и / или ZGC это будет намного «дешевле», поскольку они работают одновременно с вашим приложением. Что еще более интересно, по крайней мере, теоретически, одновременный GC не должен запускать всех фаз (достаточно было бы mark), чтобы найти то, что живо и / или мертво. Однако я сомневаюсь, что они не делают compaction также .

Если вы действительно заботитесь о STW событиях, ParallelGC может быть не очень хорошим вариантом для начала. Parallel в имени алгоритма мусора должен прозвенеть звонок: все его фазы параллельны приложению; не одновременно.

1 голос
/ 18 января 2020

Цитирование Документы для зрителей - G C Причины :

Heap_Inspection_Initiated_G C

G C было инициировано инспекционной операцией на куча. Например, вы можете вызвать это с помощью jmap : 

$ jmap -histo:live <pid>

См. Также Имеет ли JM C силу записи полета Full G C? ( ответ: да, если включена статистика кучи)
См. также Будет ли jcmd PID GC.class_histogram вызывать полный G C перед сбором данных? (ответ: да)

...