Spring Boot 如何理解G1 GC运行时间过长的原因

qyzbxkaa  于 2023-06-22  发布在  Spring
关注(0)|答案(1)|浏览(199)

我试图找出GC有时运行10-15秒的原因。大多数暂停GC都很小,但有时暂停GC时间会突然出现峰值。我在分析气相色谱记录。

2023-06-08T05:32:10.709+0000: 593903.305: [GC pause (G1 Evacuation Pause) (young), 8.9649309 secs]
   [Parallel Time: 8963.5 ms, GC Workers: 4]
      [GC Worker Start (ms): Min: 593903305.3, Avg: 593903306.2, Max: 593903308.9, Diff: 3.6]
      [Ext Root Scanning (ms): Min: 0.0, Avg: 2.4, Max: 3.3, Diff: 3.2, Sum: 9.6]
      [Update RS (ms): Min: 5.3, Avg: 5.6, Max: 6.0, Diff: 0.7, Sum: 22.3]
         [Processed Buffers: Min: 9, Avg: 62.8, Max: 84, Diff: 75, Sum: 251]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 8854.5, Avg: 8904.6, Max: 8954.6, Diff: 100.1, Sum: 35618.3]
      [Termination (ms): Min: 0.0, Avg: 49.9, Max: 100.4, Diff: 100.4, Sum: 199.8]
         [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 4]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [GC Worker Total (ms): Min: 8959.9, Avg: 8962.5, Max: 8963.5, Diff: 3.6, Sum: 35850.2]
      [GC Worker End (ms): Min: 593912268.7, Avg: 593912268.7, Max: 593912268.8, Diff: 0.1]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.1 ms]
   [Other: 1.3 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.5 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.1 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.1 ms]
   [Eden: 132.0M(132.0M)->0.0B(145.0M) Survivors: 21.0M->8192.0K Heap: 690.6M(3072.0M)->559.1M(3072.0M)]
 [Times: user=0.27 sys=0.01, real=8.97 secs] 
2023-06-08T05:32:19.674+0000: 593912.270: Total time for which application threads were stopped: 8.9664744 seconds, Stopping threads took: 0.0001051 seconds

我在这里看到真实的的GC时间明显高于user和sys时间,谁能帮我找出问题所在?

baubqpgj

baubqpgj1#

1.检查CPU使用情况

正如你所说,实时性非常大。为此,请尝试查看CPU使用情况。
另一种需要注意的情况是真实的时间比其他时间的总和大得多,这可能表明VM在可能过载的机器上没有获得足够的CPU时间。

2.减少-XX:G1 NewSizePercent

此外,从日志中,我们可以看到对象复制花费了很多时间。
[对象复制(ms):最小值:8854.5,平均值:8904.6,最大值:8954.6,差值:100.1,总和:35618.3]
您可以尝试《HotSpot Virtual Machine Garbage Collection Tuning Guide》中的以下选项。
如果“排空收集集”阶段(特别是“对象复制”子阶段)花费的时间过长,请减小-XX:G1 NewSizePercent。这减小了年轻一代的最小尺寸,从而允许可能更短的暂停。

3. Adjust -XX:MaxGCPauseMillis

您还可以使用-XX:MaxGCPauseMillis指定所需的最大暂停时间。
如果您喜欢高吞吐量,那么通过使用-XX:MaxGCPauseMillis来放松暂停时间目标,或者提供更大的堆。如果延迟是主要要求,则修改暂停时间目标。

相关问题