From 91868846e8d092e99ee8cc38558422acd554d446 Mon Sep 17 00:00:00 2001 From: 8ga Date: Thu, 13 Mar 2025 11:14:17 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=20JFR=5F1=5F=E6=9F=A5?= =?UTF-8?q?=E7=9C=8BJFR=E4=BA=8B=E4=BB=B6=E7=9A=84=E5=B7=A5=E5=85=B7JMC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- JFR_1_查看JFR事件的工具JMC.md | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/JFR_1_查看JFR事件的工具JMC.md b/JFR_1_查看JFR事件的工具JMC.md index 4558a5d..fd705c4 100644 --- a/JFR_1_查看JFR事件的工具JMC.md +++ b/JFR_1_查看JFR事件的工具JMC.md @@ -14,4 +14,22 @@ ### 使用方式 -先 dump 一份jfr记录文件，上一篇文章有介绍具体的操作方法，建议利用 begin 还有 end 参数截取你感兴趣的时间段，控制一下jfr文件的大小。然后再回到jmc里通过【文件】/【打开文件】/【选择dump的jfr文件】打开。由于jfr文件里的数据要导入内存，然后生成索引和报表，实际内存占用大概是原始文件的4~6倍左右。如果你的系统内存不足，JMC会提示你只截取一部分查看。 \ No newline at end of file +先 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。 \ No newline at end of file