G1 GC - 极长的终止时间

Question

G1 GC有时会在终止阶段花费大量时间。正如您所看到的，当GC工作者平均时间为442.9时，终止是327.3。这是处理大量消息的高性能低延迟应用程序。必须通过yong gc收集事件处理数据。通常，事件处理时间不超过150毫秒。

HW：x24 Intel（R）Xeon（R）CPU E5-2620 v3 @ 2.40GHz，32Gb内存，8Gb内存是免费的JVM选项：-server -XX：+ UseG1GC -XX：MaxGCPauseMillis = 60 -XX：ParallelGCThreads = 24 - Xmx12g -Xms12g -Xss256k Linux 2.6.32-696.6.3.el6.x86_64 java版“1.8.0_102”

通常G1将新大小设置为7Gb，年轻GC暂停为50ms，终止时间仅为6ms，集合之间的间隔为3秒。

如果应用程序产生大量长寿命物体，那么年轻暂停可能会增加，这也会导致年轻GC大小减少。但在那种情况下，终止时间保持不变。我想知道为什么终止时间可以如此剧烈地增加。

请注意此暂停的大系统时间。通常，GC暂停的系统时间为0-10ms。对于这个，它是1秒。

2017-08-23T13:21:37.690-0400: 1509.022: [GC pause (G1 Evacuation Pause) (young), 0.4474119 secs]
   [Parallel Time: 443.2 ms, GC Workers: 24]
      [GC Worker Start (ms): Min: 1509022.9, Avg: 1509023.0, Max: 1509023.4, Diff: 0.4]
      [Ext Root Scanning (ms): Min: 2.1, Avg: 22.5, Max: 90.4, Diff: 88.3, Sum: 539.7]
      [Update RS (ms): Min: 0.0, Avg: 2.2, Max: 5.0, Diff: 5.0, Sum: 54.0]
         [Processed Buffers: Min: 0, Avg: 24.7, Max: 67, Diff: 67, Sum: 592]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.7]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 26.1, Avg: 106.1, Max: 435.6, Diff: 409.6, Sum: 2545.3]
      [Termination (ms): Min: 0.0, Avg: 312.0, Max: 327.3, Diff: 327.3, Sum: 7488.6]
         [Termination Attempts: Min: 1, Avg: 1.5, Max: 4, Diff: 3, Sum: 36]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.0, Sum: 0.6]
      [GC Worker Total (ms): Min: 442.5, Avg: 442.9, Max: 443.0, Diff: 0.5, Sum: 10628.9]
      [GC Worker End (ms): Min: 1509465.9, Avg: 1509465.9, Max: 1509465.9, Diff: 0.1]
   [Code Root Fixup: 0.4 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.3 ms]
   [Other: 3.6 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 1.5 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.4 ms]
      [Humongous Register: 0.2 ms]
      [Humongous Reclaim: 0.1 ms]
      [Free CSet: 0.3 ms]
   [Eden: 476.0M(476.0M)->0.0B(556.0M) Survivors: 136.0M->56.0M Heap: 4480.6M(12.0G)->4016.3M(12.0G)]
 [Times: user=4.23 sys=1.08, real=0.45 secs]

Answer 1

我有个建议。有时，当系统上运行其他进程时，它们会与您的Java GC工作者竞争。

[对象复制（毫秒）：最小值：26.1，平均值：106.1，最大值：435.6，差值：409.6，总和：2545.3] [外部根扫描（毫秒）：最小值：2.1，平均值：22.5，最大值：90.4，差值：88.3 ，总和：539.7]

从上面的日志中，看起来GC工作人员的工作量不成比例。这意味着大多数GC线程会提前完成，其中一些仍在运行。当发生这种情况时，完成的线程试图窃取其他人的工作。这反映在终止时间中。因此，终止时间不是原因，而只是副作用。

[终止（ms）：Min：0.0，Avg：312.0，Max：327.3，Diff：327.3，Sum：7488.6]

你有一台24核机器，有24个GC工作线程。如果存在需要CPU资源的其他进程或系统活动，则可能由于争用而导致某些GC工作程序被安排延迟。

值得尝试将你的线程数减少到18并给它一个机会。

您还可以增加gc日志级别，当您执行此操作时，它会打印每个线程的开始时间。这有助于调试应用程序。