me/JFR_1_查看JFR事件的工具JMC.md

2.7 KiB
Raw Blame History

写在前面

我只是对大佬的文章内容做一个笔记,加深记忆和理解。

Java Mission Control

解压后执行 jmc.exe 无法启动的话可能是没有配置JDK环境变量或JDK版本低于 JDK 11 导致的。可以配置JDK环境变量也可以在 jmc.exe 同级目录下创建一个 jre 目录将jdk的完整目录结构拷贝至该目录都可以正常打开 jmc.exe。

使用方式

先 dump 一份jfr记录文件上一篇文章有介绍具体的操作方法,建议利用 begin 还有 end 参数截取你感兴趣的时间段控制一下jfr文件的大小。然后再回到jmc里通过【文件】/【打开文件】/【选择dump的jfr文件】打开。由于jfr文件里的数据要导入内存然后生成索引和报表实际内存占用大概是原始文件的4~6倍左右。如果你的系统内存不足JMC会提示你只截取一部分查看。

JVM调优简单示例

线上某个实例dump出了 jfr 文件。下载到本地,按照持续时间倒序查看 GC Event

有一些耗时比较高的GC 事件Old GC原因是G1 Humongous Allocation

在G1中大于 region 50的对象视为大对象,频繁分配大对象会导致性能问题。如果 region 里面包含大量的大型对象,则该 region 中最后一个具有巨型对象的区域区域末端之间的空间将不会使用,导致堆内存空间碎片化。调整的方法一般是修改 region 的大小 > 这类大对象的 2 倍以上。那么这个大对象有多大呢?我们可以通过Old Object Sample来查看老对象采样,一般随着你的程序运行时间增长,这个采集会更加准确地命中到你最关注的对象。

注意 heap used 是当前所有对象占用的内存大小。这个对象大小,可以通过数组大小计算而出,这里最大就是 3.31 * 10^6 字节。我们再来看一下当前G1HeapRegionSize的配置,通过查看Unsiged Long Flag Event

发现大小是4.19 * 10^6 字节,不足最大对象的两倍。所以我们需要将G1HeapRegionSize至少调整到 6.62 * 10^6 字节,调整之后,不再出现 G1 Old GC。