G1 GC -极长的终止时间

Question

G1 GC有时会在终止阶段花费大量时间。如您所见，GC员工的平均时间为442.9，终止时间为327.3。这是处理大量消息的高性能、低延迟的应用程序。事件处理数据必须由永gc收集。通常，事件处理不超过150 ms。

HW: x24 Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz，32 8Gb mem，8GB mem是免费的JVM选项：-server -XX:+UseG1GC -XX:MaxGCPauseMillis=60 -XX:ParallelGCThreads=24 -Xmx12g -Xms12g -Xss256k Linux 2.6.32-696.3.el6.x86_64 java版本"1.8.0_102“

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

如果应用程序产生了很多长寿的对象，那么年轻的停顿就会增加，这也会减少年轻的GC大小。但在这种情况下，终止时间保持不变。我不知道为什么终止时间会如此戏剧化地增加。

请注意此暂停的大系统时间。通常情况下，GC暂停的系统时间为0-10 is。这一次是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工作人员竞争。

对象副本(ms)：Min: 26.1，Avg: 106.1，最大值: 435.6，差: 409.6，和: 2545.3

从上面的日志来看，GC工作人员所做的工作量是不成比例的。这意味着大多数GC线程完成得很早，其中有几个还在工作。当这种情况发生时，已完成的线程试图从其他线程中窃取工作。这反映在终止时间上。因此，终止时间不是原因，而是一个副作用。

终端(ms)：Min: 0.0，Avg: 312.0，最大值: 327.3，差: 327.3，和: 7488.6

您有一个24核心机器和24个GC工作线程。如果有其他需要CPU资源的进程或系统活动，可能会有一些GC工作人员由于争用而被安排得很晚。

尝试将线程数量减少到18个并尝试一下是值得的。

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