Hotspot JVM - G1GC 堆大小调整问题

Question

我最近正在测试一个并发负载相对较高的演示应用程序。该应用程序是一个 java 应用程序，并在 Hotspot JVM (1.8.0_111) 上运行。

使用 4G 堆和并行吞吐量收集器，我可以获得大约 400 TPS 的最大吞吐量。吞吐量图表（作为负载的函数）如下所示。

因为 Oracle 建议对大于 4G 的堆大小使用 G1GC，所以我想尝试 G1，看看这是否对我的应用程序吞吐量有任何好处。

令我惊讶的是，使用 G1GC，我看到了以下吞吐量趋势。

我真的很惊讶，并决定深入了解这里发生了什么。这是我发现的。

我看到最初，在 4G 堆中，1.5G 分配给旧代区域，2.5G 分配给 eden 区域。但是随着时间的推移，旧的 gen 不再适合 1.5G，堆会被调整大小。这似乎无伤大雅。但问题似乎在于调整大小的方式。

现在所有的 4G 都分配给了旧的 gen 区域，几乎没有分配给 eden 区域。现在，当需要将某些东西分配给 eden 时，堆会再次调整大小。这成为新的常态，堆被反复调整大小，从而导致应用程序的巨大性能成本。

有没有人在 G1GC 之前注意到这一点？是否有任何建议来协商这个问题？

下面是带有 JVM 选项的启动命令行。

java -server -Xms4096m -Xmx4096m -XX:MetaspaceSize=100m -XX:MaxMetaspaceSize=100m -XX:MaxDirectMemorySize=512m -XX:MinMetaspaceFreeRatio=0 -XX:MaxMetaspaceFreeRatio=100 -XX:CompressedClassSpaceSize=20m -XX:InitialCodeCacheSize=50m -XX:ReservedCodeCacheSize=50m -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/tmp -Xloggc:/servers/logs/gc.log.2017-01-05-085234 -Djava.awt.headless=true -XX:+UnlockCommercialFeatures -XX:+FlightRecorder -Dio.netty.leakDetectionLevel=simple -XX:MaxDirectMemorySize=512m -Dadmin.connectors.http.port=9000 -Dproxy.connectors.http.port=8080 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8654 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -server -cp ...

JVM 选项：

-server 
-Xms4096m 
-Xmx4096m 
-XX:MetaspaceSize=100m 
-XX:MaxMetaspaceSize=100m 
-XX:MaxDirectMemorySize=512m 
-XX:MinMetaspaceFreeRatio=0 
-XX:MaxMetaspaceFreeRatio=100 
-XX:CompressedClassSpaceSize=20m 
-XX:InitialCodeCacheSize=50m 
-XX:ReservedCodeCacheSize=50m 
-XX:+AlwaysPreTouch 
-XX:+DisableExplicitGC 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/var/tmp 
-Xloggc:/servers/logs/gc.log.2017-01-05-085234 
-Djava.awt.headless=true 
-XX:+UnlockCommercialFeatures 
-XX:+FlightRecorder 
-Dio.netty.leakDetectionLevel=simple 
-XX:MaxDirectMemorySize=512m 
-Dadmin.connectors.http.port=9000 
-Dproxy.connectors.http.port=8080 
-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=8654 
-Dcom.sun.management.jmxremote.local.only=false 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false 
-server 
-cp ...

请在此处找到 gc 日志

Answer 1

GC原因似乎有以下两种：

• [GC暂停（G1巨大分配）（年轻）（初始标记）
• [GC暂停（G1 Evacuation Pause）（年轻）（到空间耗尽）

巨大的分配需要老一代的空间，空间耗尽会增加年轻一代的规模。他们基本上是在互相竞争。

看起来您分配大量巨大对象（> 1/2 G1 区域大小）的速度比 IHOP 启动的并发周期收集它们的速度要快。

您可以尝试增加区域大小。如果它们是大型原始数组（即不是引用数组），那么实验性的急切回收功能也可能有所帮助。