我遇到了一些与性能相关的问题(在大多数情况下都可以正常运行,并且在OSB中实现的服务中,有时会出现从100毫秒到4/5秒的响应时间的峰值,没有明显的原因)。解释这种情况的一个假设是,JVM可能在这些峰值期间执行Full GC,我们正在使用任务控制来监视JVM。
管理员告诉我jvm正在使用G1GC运行并禁用完整的gc,我可以在启动命令中看到:
-XX:+DisableExplicitGC
-XX:+UseG1GC
-XX:MaxGCPauseMillis=500 -verbosegc
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
另外,当我分析gc日志时,没有执行Full GC的记录,我只能找到(根据这些配置有意义):
2017-05-02T04:46:10.916-0700: 39228.353: [GC pause (G1 Evacuation Pause) (young), 0.0173177 secs]
但是,当我在jmc中打开飞行记录仪并开始进行负载测试时,我立即注意到正在执行完整的GC
我可以在日志中看到它:
2017-05-02T05:41:31.297: 548.719: [Full GC (Heap Inspection Initiated GC) 1780->705M(2048M), 3.040 secs]
一旦我禁用飞行记录仪,我就可以反复运行完全相同的负载测试,并且日志中不会记录完整的GC。
我在这里遗漏了一些东西,还是Flight Recorder真的迫使JVM做了Full GC'
此致
答案 0 :(得分:2)
文档says as much:
启用堆统计信息生成的航班记录将以旧GC开始和结束。在GC列表中选择旧GC,然后选择常规选项卡以将GC原因视为 -
Heap Inspection Initiated GC
。这些GC通常比其他GC需要更长的时间。
答案 1 :(得分:0)
如果在录制向导中启用堆统计,JVM将停止应用程序并扫描堆以收集有关它的信息。如果您想确保低开销(1%),请使用默认录制模板(不做修改)。
答案 2 :(得分:0)
是的,JFR录制会定期运行Full GC。我们也想知道相同但下面的文档提供了适当的细节。
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不是正确的方法。只需要一个堆转储&通过java或任何其他可用的工具使用visual vm查看它。在进行堆转储时,还要验证命令文档,以确保堆转储命令不运行GC。有可供选择的选项,需要搜索。
更新:关于您的问题中的GC假设,最好的方法是通过JVM args打印GC日志。有一些工具可以将GC日志作为输入和输入。显示具有可读统计数据的漂亮图表。因此,只需启用GC日志即可做测试。然后,当您看到问题/缓慢等时,请使用工具&看看GC开心多久了清除了多少内存等。