完整GC(堆检查启动的GC) [英] Full GC (Heap Inspection Initiated GC)

问题描述

我正在努力寻找生产JVM上的完整GC".每天午夜前后，STW发生时都没有明显的原因，十分致命，持续10-11秒.这是gc日志:

I am struggling to hunt down the "Full GC" on our production JVM. Every day at around midnight the STW occurs without apparent reason, quite deadly for 10-11 sec. Here is the gc log:

Java HotSpot(TM) 64-Bit Server VM (25.131-b11) for windows-amd64 JRE (1.8.0_131-b11), built on Mar 15 2017 01:23:53 by "java_re" with MS VC++ 10.0 (VS2010)
Memory: 4k page, physical 16584284k(13074876k free), swap 23137624k(18439472k free)
CommandLine flags: -XX:GCLogFileSize=1024000 -XX:InitialHeapSize=11811160064 -XX:+ManagementServer -XX:MaxHeapSize=11811160064 -XX:NumberOfGCLogFiles=10 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseGCLogFileRotation -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC 
...
2020-01-17T00:00:04.411+0200: 113734.053: [GC (Heap Inspection Initiated GC) [PSYoungGen: 522474K->146371K(3387904K)] 6946079K->6573263K(11077632K), 0.1786961 secs] [Times: user=0.67 sys=0.02, real=0.18 secs] 
2020-01-17T00:00:04.592+0200: 113734.233: [Full GC (Heap Inspection Initiated GC) [PSYoungGen: 146371K->0K(3387904K)] [ParOldGen: 6426892K->3217828K(7689728K)] 6573263K->3217828K(11077632K), [Metaspace: 81937K->81809K(1126400K)], 11.4447857 secs] [Times: user=44.06 sys=0.20, real=11.44 secs] 

堆检查启动的GC" 到底是什么意思?谁发起这项检查，为什么?除了它是由诸如jmap，jmc ..之类的一些我们不使用的工具引起的，我没有找到有关它的任何有意义的信息.

What "Heap Inspection Initiated GC" actually means? Who initiates this inspection and why? I've failed to find any meaningful information about it other than it gets caused by some tools like jmap, jmc.. which we don't use.

任何提示或指示都将受到高度赞赏.

Any hint or direction is highly appreciated.

推荐答案

JVM代理可以触发GC不需要触发所有阶段的所有(mark就足够了)来找到有效的和/或无效的.但是，我怀疑他们不会同时执行compaction .

A JVM agent can trigger a heap inspection too. To know the liveness of Objects at the current moment, you need to trigger a Full GC call. I guess in cases of Shenandoah and/or ZGC this would be a lot "cheaper", since they work concurrently with your application. What is even more interesting, that in theory at least, a concurrent GC does not need to trigger all of the phases (mark would be enough) to find what is live and/or dead. However, I doubt that they don't do compaction also.

如果您真的很关心STW事件，那么ParallelGC可能不是一个很好的选择.垃圾算法名称中的Parallel应该敲响警钟:它的所有阶段都与应用程序平行； 不并发.

If you really care about STW events, ParallelGC might not be a very good option to begin with. Parallel in the name of the garbage algorithm should ring a bell: all of its phases are parallel to the application; not concurrent.

这篇关于完整GC(堆检查启动的GC)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！