java - 如何调整 JVM 8 G1 参数以避免 Full GC(分配失败)

Question

在 XMX 为 8 GB 的服务器中使用 G1 GC 时，运行几天后会发生 Full GC 失败。

尝试多次调整 JVM GC 参数，并打印出所有 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 详细信息:

2019-01-25T00:25:28.998+0800: 399236.910: [GC pause (G1 Evacuation Pause) (young) (initial-mark) (to-space exhausted), 0.3400461 secs]
[Eden: 1080.0M(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)->7936.0M(8192.0M)] [Times: user=2.22 sys=0.01, real=0.34 secs] 2019-01-25T00:25:29.338+0800: 399237.251: [GC concurrent-root-region-scan-start] 2019-01-25T00:25:29.338+0800: 399237.251: [GC concurrent-root-region-scan-end, 0.0000869 secs] 2019-01-25T00:25:29.338+0800: 399237.251: [GC concurrent-mark-start] 2019-01-25T00:25:29.419+0800: 399237.332: [GC pause (G1 Evacuation Pause) (young) (to-space exhausted), 0.2033834 secs] [Eden: 208.0M(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)->8144.0M(8192.0M)] [Times: user=0.67 sys=0.02, real=0.21 secs] 2019-01-25T00:25:29.624+0800: 399237.537: [GC pause (G1 Evacuation Pause) (young), 0.0076649 secs] [Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)->8144.0M(8192.0M)] [Times: user=0.07 sys=0.00, real=0.01 secs] 2019-01-25T00:25:29.632+0800: 399237.545: [GC pause (G1 Evacuation Pause) (young), 0.0072213 secs] [Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)->8144.0M(8192.0M)] [Times: user=0.06 sys=0.00, real=0.01 secs] 2019-01-25T00:25:29.640+0800: 399237.553: [GC pause (G1 Evacuation Pause) (young), 0.0032099 secs] [Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)->8144.0M(8192.0M)] [Times: user=0.02 sys=0.01, real=0.00 secs] 2019-01-25T00:25:29.645+0800: 399237.557: [GC pause (G1 Evacuation Pause) (young), 0.0041076 secs] [Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)->8144.0M(8192.0M)] [Times: user=0.03 sys=0.00, real=0.00 secs] 2019-01-25T00:25:29.649+0800: 399237.562: [GC pause (G1 Evacuation Pause) (young), 0.0027963 secs] [Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 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 pause (G1 Evacuation Pause) (young), 0.0027614 secs] [Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)->8144.0M(8192.0M)] [Times: user=0.02 sys=0.00, real=0.00 secs] 2019-01-25T00:25:29.656+0800: 399237.569: [Full GC (Allocation Failure) 8144M->4016M(8192M), 10.6192450 secs] [Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)->4016.1M(8192.0M)], [Metaspace: 83995K->83979K(1126400K)] [Times: user=15.73 sys=0.00, real=10.62 secs] 2019-01-25T00:25:40.277+0800: 399248.190: [GC concurrent-mark-abort] Heap garbage-first heap total 8388608K, used 4268154K [0x00000005c0000000, 0x00000005c0802000, 0x00000007c0000000) region size 8192K, 20 young (163840K), 0 survivors (0K) Metaspace
used 84034K, capacity 85146K, committed 86732K, reserved 1126400K
class space used 8833K, capacity 9090K, committed 9420K, reserved 1048576K

<小时/>

我们的服务器是32G 16核，任何意见或建议将不胜感激!

Answer 1

这很复杂。

在日志中，我发现由于老年代进行的full GC太小了。

“分配失败”表明直接分配到老年代失败。

但是，从日志中我也发现full GC之前的minor GC过于频繁，释放了一点空间。 25:29.338 25:29.653之间发生了7次minor GC。只有第一次minor GC释放了一些空间。

最严重的问题是“[Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B”。看来所有对象都是在老年代分配的。从日志“[Eden: 0.0B(3072.0M)->0.0B(3072.0M) Survivors: 0.0B->0.0B Heap: 8144.0M(8192.0M)-> 4016.1M(8192.0M)]”，我认为这次full GC释放了4000M+老年代空间。这很奇怪。您的应用程序至少需要 4G 老年代，并且几乎所有老年代中的对象都被回收。这意味着旧对象还不够旧。他们中的大多数人都过早地获得晋升。或者其中许多都是巨大的物体。

我试着给你一些建议......

1. -XX:InitiatingHeapOccupancyPercent=35 太小。它会使 Minor GC 更加频繁，并且对象可能会过早提升。所以老年代很快就满了。您可以将 XX:InitiatingHeapOccupancyPercent 设置得更大。或者您可以考虑自适应 IHOP。

2. 老年代太小。某些应用程序需要比年轻代空间更多的老年代空间。有人说年轻代空间大小的两倍或三倍就很好。

3. MaxTenuringThreshold=15 可以设置为大于 20 的值。

   • understanding g1 gc log
   • G1 Collector