почему g1 gc не может собрать много после использования кучи больше, чем IHOP? - PullRequest
Новая
       41

почему g1 gc не может собрать много после использования кучи больше, чем IHOP?

0 голосов
/ 16 октября 2019

В настоящее время я использую G1 GC в своем серверном приложении. Версия Java - 1.8.0_121. Основные параметры JVM: 

-Xmx24G
-Xms24G
-XX:MaxGCPauseMillis=500
-XX:InitiatingHeapOccupancyPercent=65
-XX:G1MixedGCLiveThresholdPercent=80
-XX:G1OldCSetRegionThresholdPercent=5
-XX:G1HeapRegionSize=8m
-XX:G1MixedGCCountTarget=64
-XX:G1HeapWastePercent=5
-XX:ParallelGCThreads=12
-XX:ConcGCThreads=6
-XX:+ParallelRefProcEnabled

по умолчанию, когда old gen достигает 15,6G (IHOP = 65%), параллельный цикл будет запущен и начнется смешиваниедс. Когда трафик увеличился, старый gen стал больше чем 15,6G, я видел журналы gc ниже, это показывает, что параллельный цикл был запущен, но не может собрать достаточно памяти в старом gen, и затем, кажется, входит в порочный цикл(запустить параллельный цикл -> не запускать смешанную сборку мусора), наконец, был запущен полный сборщик мусора. 

3041487.573: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 17993564160 bytes, allocation request: 0 bytes, threshold: 16750372405 bytes (65.00 %), source: end of GC]
...
3041538.002: [G1Ergonomics (Concurrent Cycles) initiate concurrent cycle, reason: concurrent cycle initiation requested]
...
2019-10-14T22:23:55.286+0800: 3041538.080: [GC concurrent-root-region-scan-start]
2019-10-14T22:23:55.286+0800: 3041538.080: [GC concurrent-string-deduplication, 1968.0B->1000.0B(968.0B), avg 64.3%, 0.0000461 secs]
2019-10-14T22:23:55.302+0800: 3041538.096: [GC concurrent-root-region-scan-end, 0.0158618 secs]
2019-10-14T22:23:55.302+0800: 3041538.096: [GC concurrent-mark-start]
2019-10-14T22:24:00.792+0800: 3041543.586: [GC concurrent-mark-end, 5.4896522 secs]
2019-10-14T22:24:00.796+0800: 3041543.590: [GC remark 2019-10-14T22:24:00.796+0800: 3041543.590: [Finalize Marking, 0.0005937 secs] 2019-10-14T22:24:00.797+0800: 3041543.591: [GC ref-proc, 0.0098316 secs] 2019-10-14T22:24:00.806+0800: 3041543.601: [Unloading, 0.0084653 secs], 0.0626567 secs]
 [Times: user=0.49 sys=0.16, real=0.07 secs] 
2019-10-14T22:24:00.861+0800: 3041543.655: [GC cleanup 17G->17G(24G), 0.4346713 secs]
 [Times: user=2.81 sys=2.21, real=0.43 secs] 
2019-10-14T22:24:30.944+0800: 3041573.738: [GC pause (G1 Evacuation Pause) (young) 3041573.739: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 61877, predicted base time: 48.33 ms, remaining time: 451.67 ms, target pause time: 500.00 ms]
 3041573.739: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 601 regions, survivors: 9 regions, predicted young region time: 23.17 ms]
 3041573.739: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 601 regions, survivors: 9 regions, old: 0 regions, predicted pause time: 71.50 ms, target pause time: 500.00 ms]
 3041573.840: [G1Ergonomics (Concurrent Cycles) do not request concurrent cycle initiation, reason: still doing mixed collections, occupancy: 17993564160 bytes, allocation request: 0 bytes, threshold: 16750372405 bytes (65.00 %), source: end of GC]
 3041573.840: [G1Ergonomics (Mixed GCs) do not start mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 393 regions, reclaimable: 1288200624 bytes (5.00 %), threshold: 5.00 %]
, 0.1012637 secs]

Я обнаружил, что даже если трафик стал нормальным, пока занятость старого поколения была больше, чемIHOP, это случится. Так как мне настроить параметры JVM, чтобы избежать такой ситуации?

...