简体   繁体   English

Full GC(堆检查启动的 GC)

[英]Full GC (Heap Inspection Initiated GC)

I am struggling to hunt down the "Full GC" on our production JVM.我正在努力寻找我们生产 JVM 上的“Full GC”。 Every day at around midnight the STW occurs without apparent reason, quite deadly for 10-11 sec.每天在午夜左右,STW 会在没有明显原因的情况下发生,持续 10-11 秒非常致命。 Here is the gc log:这是gc日志:

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? “堆检查启动的 GC”实际上是什么意思? 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.除了它是由我们不使用的一些工具(如 jmap、jmc ......)引起的之外,我没有找到任何关于它的有意义的信息。

Any hint or direction is highly appreciated.任何提示或方向都受到高度赞赏。

A JVM agent can trigger a heap inspection too . JVM代理也可以触发堆检查 To know the liveness of Objects at the current moment, you need to trigger a Full GC call.要了解当前时刻对象的活跃度,您需要触发Full GC调用。 I guess in cases of Shenandoah and/or ZGC this would be a lot "cheaper", since they work concurrently with your application.我想在Shenandoah和/或ZGC情况下,这会“便宜”很多,因为它们与您的应用程序同时工作。 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.更有趣的是,至少在理论上,并发GC不需要触发所有阶段( mark就足够了)来查找活动和/或死亡的阶段。 However, I doubt that they don't do compaction also .然而,我怀疑他们不做compaction

If you really care about STW events, ParallelGC might not be a very good option to begin with.如果您真的很关心STW事件,那么ParallelGC可能不是一个很好的开始选择。 Parallel in the name of the garbage algorithm should ring a bell: all of its phases are parallel to the application;以垃圾算法的名义Parallel应该敲响警钟:它的所有阶段都与应用程序并行; not concurrent.并发。

Quoting Spectator Docs - GC Causes :引用Spectator Docs - GC 原因

Heap_Inspection_Initiated_GC Heap_Inspection_Initiated_GC

GC was initiated by an inspection operation on the heap. GC 是由对堆的检查操作启动的。 For example you can trigger this with jmap :例如,您可以使用jmap触发此操作:

 $ jmap -histo:live <pid>

See also Does JMC Flight Recording force Full GC?另请参阅JMC Flight Recording 是否强制执行 Full GC? (answer: yes, if Heap Statistics enabled) (答案:是的,如果启用堆统计)
See also Will jcmd PID GC.class_histogram call a full GC before collecting data?另请参阅jcmd PID GC.class_histogram在收集数据之前jcmd PID GC.class_histogram调用完整的 GC? (answer: yes) (答案:是)

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

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