在OSB中实现的服务中,我遇到了一些与性能相关的问题(大多数情况下工作正常,有时响应时间会从100ms激增到4/5s,没有明显的原因)。解释这种情况的一个假设是,在这些峰值期间,JVM可能正在执行完整的GC,而我们正在使用任务控制来监控JVM。
管理员告诉我,jvm使用G1GC在禁用完全gc的情况下运行,我可以在启动命令中看到这一点:
-XX:+DisableExplicitGC
-XX:+UseG1GC
-XX:MaxGCPauseMillis=500 -verbosegc
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps 此外,当我分析gc日志时,没有执行完整GC的日志记录,我只能发现(基于这些配置这是有意义的):
2017-05-02T04:46:10.916-0700: 39228.353: [GC pause (G1 Evacuation Pause) (young), 0.0173177 secs]然而,当我在jmc中打开飞行记录器并开始一些负载测试时,我立即注意到正在执行完整的GCs。

我可以在日志中看到:
2017-05-02T05:41:31.297: 548.719: [Full GC (Heap Inspection Initiated GC) 1780->705M(2048M), 3.040 secs]一旦我禁用了飞行记录器,我就可以一遍又一遍地运行完全相同的负载测试,日志中不会记录完整的GC。
我是不是漏掉了什么,或者是Flight Recorder真的迫使JVM执行完整的GC?
问候
发布于 2017-05-04 01:23:28
启用堆统计信息后生成的飞行记录将以旧GC开始和结束。在GC列表中选择旧GC,然后选择General选项卡以-
Heap Inspection Initiated GC形式查看GC原因。这些GC通常比其他GC花费的时间稍长。
发布于 2017-05-04 06:43:14
如果您在记录向导中启用了Heap Statistics,JVM将停止应用程序并清扫堆以收集有关它的信息。如果您希望确保低开销(1%),请使用默认录制模板(未修改)。
发布于 2017-07-21 12:50:14
是的,JFR记录确实会定期运行完整的GC。INitially我们也想知道同样的事情,但下面的文档给出了适当的细节。
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr005.html
The flight recording generated with Heap Statistics enabled will start and end with an old GC. Select that old GC in the list of GCs, and then choose the General tab to see the GC Reason as - Heap Inspection Initiated GC. These GCs usually take slightly longer than other GCs.基本上,我们的想法是查看即使在GC之后也没有收集到的对象,这会导致内存泄漏。
如果您只想查看整个堆来了解堆中的所有对象,那么JFR不是正确的方法。只需获取一个堆转储&使用visual vm、java或任何其他免费工具查看它。在获取堆转储的同时,还要验证命令的文档,以确保堆转储命令不会运行GC。有可供选择的选项,需要搜索。
更新:同样关于您问题中的GC假设,最好的方法是通过JVM args打印GC日志。有一些工具可以将GC日志作为输入,并以可读的统计数据显示漂亮的图形。因此,只需启用GC日志并进行测试即可。然后,当您看到问题/速度缓慢等问题时,使用工具查看GC日志&查看GC发生了多长时间&有多少内存被清除等。
https://stackoverflow.com/questions/43757177
复制相似问题