简体   繁体   中英

Full GC (Heap Inspection Initiated 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] 

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.

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 .

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.

Quoting Spectator Docs - GC Causes :

Heap_Inspection_Initiated_GC

GC was initiated by an inspection operation on the heap. For example you can trigger this with jmap :

 $ jmap -histo:live <pid>

See also Does JMC Flight Recording force Full GC? (answer: yes, if Heap Statistics enabled)
See also Will jcmd PID GC.class_histogram call a full GC before collecting data? (answer: yes)

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM