我在我的在线hbase服务中发现一段gc日志,如下所示:
2018-11-08T19:12:35.907+0800: 4069334.381: [GC pause (G1 Evacuation Pause) (young)
Desired survivor size 41943040 bytes, new threshold 1 (max 1)
- age 1: 23290768 bytes, 23290768 total
, 1.9809681 secs]
[Parallel Time: 22.6 ms, GC Workers: 13]
[GC Worker Start (ms): Min: 4069334380.9, Avg: 4069334381.1, Max: 4069334381.2, Diff: 0.3]
[Ext Root Scanning (ms): Min: 0.8, Avg: 1.0, Max: 1.1, Diff: 0.3, Sum: 12.8]
[Update RS (ms): Min: 1.6, Avg: 1.8, Max: 2.0, Diff: 0.4, Sum: 23.4]
[Processed Buffers: Min: 1, Avg: 4.4, Max: 9, Diff: 8, Sum: 57]
[Scan RS (ms): Min: 2.2, Avg: 2.4, Max: 2.5, Diff: 0.3, Sum: 30.9]
[Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
[Object Copy (ms): Min: 6.7, Avg: 7.5, Max: 17.0, Diff: 10.4, Sum: 97.9]
[Termination (ms): Min: 0.0, Avg: 9.5, Max: 10.3, Diff: 10.3, Sum: 123.1]
[Termination Attempts: Min: 1, Avg: 2.5, Max: 5, Diff: 4, Sum: 33]
[GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.3]
[GC Worker Total (ms): Min: 22.1, Avg: 22.2, Max: 22.3, Diff: 0.3, Sum: 288.5]
[GC Worker End (ms): Min: 4069334403.3, Avg: 4069334403.3, Max: 4069334403.3, Diff: 0.0]
[Code Root Fixup: 0.0 ms]
[Code Root Purge: 0.0 ms]
[Clear CT: 0.4 ms]
[Other: 1957.9 ms]
[Choose CSet: 0.0 ms]
[Ref Proc: 4.2 ms]
[Ref Enq: 1951.7 ms]
[Redirty Cards: 1.2 ms]
[Humongous Register: 0.0 ms]
[Humongous Reclaim: 0.0 ms]
[Free CSet: 0.3 ms]
[Eden: 592.0M(592.0M)->0.0B(592.0M) Survivors: 32.0M->32.0M Heap: 6521.8M(12.2G)->5943.3M(12.2G)]
[Times: user=0.19 sys=0.11, real=1.98 secs]
正如你所看到的,大部分时间都花在 Ref Enq
. 我能做些什么来优化这个。
1条答案
按热度按时间0mkxixxg1#
关于处理引用对象所用时间的信息显示在ref proc和ref enq阶段。在refproc阶段,g1根据引用对象特定类型的需求更新引用对象。在ref enq中,如果发现引用对象的引用死了,g1将引用对象排到各自的引用队列中。
如果这些阶段花费的时间太长,那么考虑使用-xx:+parallelrefprocenabled选项来启用这些阶段的并行化
更多信息--->
https://docs.oracle.com/javase/10/gctuning/garbage-first-garbage-collector-tuning.htm#jsgct-guid-0bb3b742-a985-4d5e-a9c5-433a127fe0f6