[英]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.