Как настроить аргумент JVM 8 G1, чтобы избежать Full GC (ошибка распределения)

Question

При использовании G1 GC на сервере с XMX 8 ГБ сбой полного GC происходит через несколько дней работы.

Попробуйте настроить несколько аргументов GC JVM и распечатать все детали GC, но все еще не можете определить основную причину

Аргументы JVM :

java -Xms8g -Xmx8g 
-XX:+CrashOnOutOfMemoryError 
-XX:+AlwaysPreTouch 
-XX:-UseBiasedLocking 
-XX:MaxTenuringThreshold=15 
-Xss256k 
-XX:SurvivorRatio=6 
-XX:+UseTLAB 
-XX:GCTimeRatio=4 
-XX:+ScavengeBeforeFullGC 
-XX:G1HeapRegionSize=8M 
-XX:ConcGCThreads=8 
-XX:G1HeapWastePercent=10 
-XX:+AggressiveOpts 
-XX:MaxMetaspaceSize=256m 
-XX:+UseG1GC 
-XX:InitiatingHeapOccupancyPercent=35 
-XX:+DisableExplicitGC 
-Xloggc:/var/tmp/prod/query/Portfolio/PORTFOLIO-QRY-A-Instance1/query-gc.log
-verbose:gc 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+PrintGCTimeStamps 
-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=10 
-XX:GCLogFileSize=100M 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/var/tmp/prod/query/xxx.log-XX:NewSize=3g 
-XX:MaxNewSize=5g 
-server

Последние данные GC: * ​​1011 *

2019-01-25T00: 25: 28.998 + 0800: 399236.910: [Пауза GC (G1 Evacuation Pause) (молодая)(начальная отметка) (исчерпано пространство), 0,3400461 с]
[Eden: 1080,0M (3072,0M) -> 0,0B (3072,0M) Выжившие: 0,0B-> 0,0B Куча: 8144,0M (8192,0M)) -> 7936,0M (8192,0M)] [Время: пользователь = 2,22 sys = 0,01, реальное = 0,34 с] 2019-01-25T00: 25: 29,338 + 0800: 399237.251: [GC concurrent-root-region-scan-start-start] 2019-01-25T00: 25: 29.338 + 0800: 399237.251: [GC concurrent-root-region-scan-end, 0.0000869 секунд] 2019-01-25T00: 25: 29.338 + 0800: 399237.251: [GC concurrent-mark-начало] 2019-01-25T00: 25: 29.419 + 0800: 399237.332: [Пауза ГХ (Пауза эвакуации G1) (молодой) (истощен в космос), 0,2033834 с] [Иденум: 208,0M (3072,0M) -> 0,0B(3072,0M) Выжившие: 0,0B-> 0,0B Куча: 8144,0M (8192,0M) -> 8144,0M (8192,0)M)] [Время: пользователь = 0,67 сис = 0,02, реальное = 0,21 с] 2019-01-25T00: 25: 29,624 + 0800: 399237,537: [Пауза GC (G1 Evacuation Pause) (молодая), 0,0076649 с] [Иден:0.0B (3072.0M) -> 0.0B (3072.0M) Выжившие: 0.0B-> 0.0B Куча: 8144.0M (8192.0M) -> 8144.0M (8192.0M)] [Times: user = 0.07 sys = 0.00, real= 0,01 с] 2019-01-25T00: 25: 29,632 + 0800: 399237,545: [GC-пауза (G1 Evacuation Pause) (молодые), 0,0072213 с] [Eden: 0,0B (3072,0M) -> 0,0B (3072,0M)Выжившие: 0,0B-> 0,0B Куча: 8144,0M (8192,0M) -> 8144,0M (8192,0M)] [Times: user = 0,06 sys = 0,00, real = 0,01 с] 2019-01-25T00: 25: 29,640+0800: 399237.553: [GC пауза (G1 Evacuation Pause) (молодой), 0,0032099 с] [Eden: 0,0B (3072,0M) -> 0,0B (3072,0M) Выжившие: 0,0B-> 0,0B Куча: 8144,0M (8192,0)M) -> 8144,0M (8192,0M)] [Время: пользователь = 0,02 sys = 0,01, реальное = 0,00 с] 2019-01-25T00: 25: 29,645 + 0800: 399237,557: [GC-пауза (G1 Evacuation Pause) (молодой), 0,0041076 с] [Eden: 0,0B (3072,0M) -> 0,0B (3072,0M) Выжившие: 0,0B-> 0,0B Куча: 8144,0M (8192,0M) -> 8144,0M (8192,0M)] [Times:пользователь = 0,03 сис = 0.00, реальное = 0,00 с] 2019-01-25T00: 25: 29,649 + 0800: 399237,562: [GC-пауза (G1 Evacuation Pause) (молодые), 0,0027963 с] [Eden: 0,0B (3072,0M) -> 0,0B (3072.0M) Оставшиеся в живых: 0.0B-> 0.0B Куча: 8144.0M (8192.0M) -> 8144.0M (8192.0M)] [Times: user = 0.01 sys = 0.00, real = 0.01 secs] 2019-01-25T00: 25: 29.653 + 0800: 399237.566: [GC пауза (G1 Evacuation Pause) (молодые), 0,0027614 с] [Eden: 0,0B (3072,0M) -> 0,0B (3072,0M) Выжившие: 0,0B-> 0,0B Куча: 8144,0M (8192,0M) -> 8144,0M (8192,0M)] [Время: пользователь = 0,02 sys = 0,00, реальное = 0,00 с] 2019-01-25T00: 25: 29,656 + 0800: 399237,569: [Полный GC (ошибка выделения)8144M-> 4016M (8192M), 10,6192450 с] [Eden: 0,0B (3072,0M) -> 0,0B (3072,0M) Выжившие: 0,0B-> 0,0B Куча: 8144,0M (8192,0M) -> 4016,1M (8192,0)M)], [Metaspace: 83995K-> 83979K (1126400K)] [Times: user = 15,73 sys = 0.00, real = 10.62 секунды] 2019-01-25T00: 25: 40.277 + 0800: 399248.190: [GC concurrent-mark-abort] Общая куча мусора - первая куча 8388608K, использовано 4268154K [0x00000005c0000000, 0x00000005c0802000, 0x00000007c0000000) размер области 8192K, 20 молодых (163840K), 0 выживших (0K) Metaspace
использовано 84034K, емкость 85146K, выделено 86732K, зарезервировано 1126400K
использовано пространство класса 8833K, емкость 9090K, выделено 9420K, зарезервировано 1048576K

---

Наш сервер является 32G 16-ядерным, любой совет или предложение будут очень благодарны!

Answer 1

Это сложно.

В журналах я обнаружил, что выполнение полного GC из-за старого поколения слишком мало.

«Ошибка выделения» показала, что прямое выделение старому поколению не удалось,

Но из журналов я также обнаружил, что второстепенные GC до полного GC слишком часты и занимают немного места.Между 25: 29.338 и 25: 29.653 было 7 второстепенных ГК. First Только первый младший ГК освободил место: 0.0B-> 0.0B ».Кажется, что все объекты размещены в старом поколении. Из журнала "[Eden: 0.0B (3072.0M) -> 0.0B (3072.0M) Выжившие: 0.0B-> 0.0B Heap: 8144.0M (8192.0M) ->4016.1M (8192.0M)] ", я думаю, что этот полный GC освободил 4000M + пространство старого поколения.Это очень странно.Вашему приложению требуется как минимум 4G старого поколения, и почти все объекты старого поколения возвращаются.Это означает, что старые объекты недостаточно стары.Большинство из них продвигаются преждевременно.Или многие из них являются огромными объектами.

Я пытаюсь дать вам несколько советов ...

1. -XX: InitiatingHeapOccupancyPercent = 35 слишком мало. Этоделает незначительные GC более частыми, и объекты могут быть продвинуты преждевременно.Так что старое поколение скоро будет полным.Вы можете установить XX: InitiatingHeapOccupancyPercent больше.Или вы можете подумать об адаптивном IHOP.

2. Старое поколение слишком мало. Некоторым приложениям требуется гораздо больше пространства старого поколения, чем пространства молодого поколения.Кто-то говорит, что размер двойного или тройного пространства молодого поколения - это хорошо.

3. MaxTenuringThreshold = 15 может установить значение больше 20.

   • понимание g1 gc log
   • G1 Collector