Question

我们有一个Java应用程序，配置为使用Java 6和G1GC 集电极。最近我们观察到Full GC在重复尝试中陷入困境即使有足够的内存（每个GC日志）。有没有人遇到过 Java 6 G1GC组合的场景？

GC配置：

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M -XX:-OmitStackTraceInFastThrow -XX:`enter code here`+UseG1GC -XX:InitiatingHeapOccupancyPercent=72  -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

GC日志：

9  172169595.9  172169595.9  172169595.9  172169595.9]
      [Other:   0.4 ms]
   [Clear CT:   0.8 ms]
   [Other:   2.1 ms]
      [Choose CSet:   0.0 ms]
   [ 6526M->6456M(14848M)]
 [Times: user=0.20 sys=0.00, real=0.02 secs]
2018-03-08T15:51:22.822+0000: 172169.607: [Full GC 6456M->4080M(14848M), 6.7084910 secs]
 [Times: user=11.75 sys=0.02, real=6.70 secs]
172177.358: [GC pause (young), 0.01637700 secs]
   [Parallel Time:  13.9 ms]
      [GC Worker Start Time (ms):  172177359.4  172177359.5  172177359.5  172177359.5  172177359.5  172177359.5  172177359.6  172177359.6  172177359.6  172177359.6  172177359.7  172177359.7  172177359.7  172177359.7  172177359.8  172177359.8  172177359.8  172177359.8]
      [Update RS (ms):  2.5  1.5  2.2  2.2  2.3  2.2  2.3  2.1  2.2  2.5  1.5  1.5  1.0  1.5  2.3  1.6  1.9  2.2
       Avg:   2.0, Min:   1.0, Max:   2.5]
         [Processed Buffers : 12 106 62 1 1 1 1 1 1 83 113 149 62 136 1 76 1 1
          Sum: 808, Avg: 44, Min: 1, Max: 149]
      [Ext Root Scanning (ms):  4.6  5.6  5.5  5.4  5.2  5.4  5.3  5.3  5.0  4.4  5.4  5.3  5.9  5.3  5.1  5.2  5.2  5.1
       Avg:   5.2, Min:   4.4, Max:   5.9]
      [Mark Stack Scanning (ms):  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
       Avg:   0.0, Min:   0.0, Max:   0.0]
      [Scan RS (ms):  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
       Avg:   0.0, Min:   0.0, Max:   0.0]
      [Object Copy (ms):  6.3  6.3  5.7  5.8  5.8  5.7  5.7  5.9  6.1  6.3  6.3  6.3  6.3  6.3  5.7  6.3  6.0  5.7
       Avg:   6.0, Min:   5.7, Max:   6.3]
      [Termination (ms):  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
       Avg:   0.0, Min:   0.0, Max:   0.0]
         [Termination Attempts : 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
          Sum: 18, Avg: 1, Min: 1, Max: 1]
      [GC Worker End Time (ms):  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9  172177372.9]
      [Other:   0.6 ms]
   [Clear CT:   0.3 ms]
   [Other:   2.2 ms]
      [Choose CSet:   0.0 ms]
   [ 6543M->6473M(14848M)]
 [Times: user=0.22 sys=0.00, real=0.01 secs]
2018-03-08T15:51:30.598+0000: 172177.384: [Full GC 6473M->4098M(14848M), 6.7136020 secs]
 [Times: user=11.72 sys=0.01, real=6.71 secs]
172185.070: [GC pause (young), 0.02292200 secs]
   [Parallel Time:  19.0 ms]
      [GC Worker Start Time (ms):  172185071.9  172185072.0  172185072.0  172185072.1  172185072.1  172185072.2  172185072.2  172185072.2  172185072.2  172185072.3  172185072.3  172185072.3  172185072.3  172185072.4  172185072.4  172185072.4  172185072.5  172185072.5]
      [Update RS (ms):  5.4  5.5  4.1  5.2  9.9  3.7  5.0  4.2  4.5  3.8  3.7  4.7  3.8  3.7  4.8  4.5  3.8  5.5
       Avg:   4.8, Min:   3.7, Max:   9.9]
         [Processed Buffers : 3 2 3 2 2 109 3 2 2 58 68 100 107 69 62 121 97 2
          Sum: 812, Avg: 45, Min: 2, Max: 121]
      [Ext Root Scanning (ms):  5.8  5.5  5.7  5.3  6.0  5.5  5.4  5.6  5.2  5.3  5.4  4.5  5.3  5.3  4.3  4.5  5.1  5.1
       Avg:   5.3, Min:   4.3, Max:   6.0]
      [Mark Stack Scanning (ms):  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
       Avg:   0.0, Min:   0.0, Max:   0.0]
      [Scan RS (ms):  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.1  0.0  0.0  0.0  0.0  0.0  0.0  0.0
       Avg:   0.0, Min:   0.0, Max:   0.1]

Answer 1

我还认为你应该更新你的JVM。但是，据我所知，有些时候这并不容易，当JDK8与JDK7进行比较时，您可以看到对GC1的一些改进

来源：https://www.redhat.com/en/blog/part-1-introduction-g1-garbage-collector

一些巨大的物体可能不会引起问题，但是稳定它们的分配可能导致严重的堆碎片和a 显着的性能影响。在JDK8u40之前，它是一个幽默的物体只能通过一个完整的GC收集，所以有可能影响JDK7和早期的JDK8用户非常高。这就是为什么了解应用程序对象的大小至关重要产生以及G1为区域大小定义的内容。即使是最新的 JDK8，如果你做了大量的大量分配，尽可能多地评估和调整
是一个好主意

此外，在本文中您可以看到：

最后，不幸的是，G1还必须处理可怕的Full GC。虽然G1最终试图避免使用Full GC，但它们仍然是严酷的现实，尤其是在调整不当的环境中。鉴于 G1的目标是更大的堆大小，Full GC的影响可以对飞行中的处理和SLA造成灾难性后果。其中一个主要的原因是 Full GCs仍然是单线程操作 G1 即可。看看原因，第一个，也是最可以避免的，与之相关元空间。

顺便说一下，似乎是最新版本的Java（10）将包含一个能够并行执行Full GC的G1。

https://www.opsian.com/blog/java-10-with-g1/

Java 10通过迭代改进其来减少完整GC暂停时间现有算法。 直到Java 10 G1 Full GCs在单个线程中运行。这是对的 - 你的32核服务器和它的128GB将停止和暂停直到一个线程取出垃圾。

Java 6 G1GC - 重复完整GC

1 个答案: