JVM的GC日志的主要参数包括如下几个:
-XX:+PrintGC 输出GC日志
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳(以基准时间的形式)
-XX:+PrintGCDateStamps 输出GC的时间戳(以日期的形式,如 2013-05-04T21:53:59.234+0800)
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-Xloggc:../logs/gc.log 日志文件的输出路径
在我做了如下的设置
-XX:+PrintGCDetails -Xloggc:../logs/gc.log -XX:+PrintGCTimeStamps
以后打印出来的日志为:
0.756: [Full GC (System) 0.756: [CMS: 0K->1696K(204800K), 0.0347096 secs] 11488K->1696K(252608K), [CMS Perm : 10328K->10320K(131072K)], 0.0347949 secs] [Times: user=0.06 sys=0.00, real=0.05 secs] 1.728: [GC 1.728: [ParNew: 38272K->2323K(47808K), 0.0092276 secs] 39968K->4019K(252608K), 0.0093169 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 2.642: [GC 2.643: [ParNew: 40595K->3685K(47808K), 0.0075343 secs] 42291K->5381K(252608K), 0.0075972 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] 4.349: [GC 4.349: [ParNew: 41957K->5024K(47808K), 0.0106558 secs] 43653K->6720K(252608K), 0.0107390 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] 5.617: [GC 5.617: [ParNew: 43296K->7006K(47808K), 0.0136826 secs] 44992K->8702K(252608K), 0.0137904 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] 7.429: [GC 7.429: [ParNew: 45278K->6723K(47808K), 0.0251993 secs] 46974K->10551K(252608K), 0.0252421 secs]
我们取倒数第二条记录分析一下各个字段都代表了什么含义
5.617(时间戳): [GC(Young GC) 5.617(时间戳): [ParNew(使用ParNew作为年轻代的垃圾回收期): 43296K(年轻代垃圾回收前的大小)->7006K(年轻代垃圾回收以后的大小)(47808K)(年轻代的总大小), 0.0136826 secs(回收时间)] 44992K(堆区垃圾回收前的大小)->8702K(堆区垃圾回收后的大小)(252608K)(堆区总大小), 0.0137904 secs(回收时间)] [Times: user=0.03(Young GC用户耗时) sys=0.00(Young GC系统耗时), real=0.02 secs(Young GC实际耗时)]
我们再对数据做一个简单的分析
从最后一条GC记录中我们可以看到 Young GC回收了 45278-6723=38555K的内存
Heap区通过这次回收总共减少了 46974-10551=36423K的内存。
38555-36423=2132K说明通过该次Young GC有2132K的内存被移动到了Old Gen,
我们来验证一下
在最后一次Young GC的回收以前 Old Gen的大小为8702-7006=1696
回收以后Old Gen的内存使用为10551-6723=3828
Old Gen在该次Young GC以后内存增加了3828-1696=2132K 与预计的相符
重新设置GC日志的输出
-XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -verbose:gc -Xloggc:gc.log
后可以看到进行GC前后的堆内存信息
{Heap before GC invocations=1 (full 0): PSYoungGen total 152896K, used 131072K [0x00000000f5560000, 0x0000000100000000, 0x0000000100000000) eden space 131072K, 100% used [0x00000000f5560000,0x00000000fd560000,0x00000000fd560000) from space 21824K, 0% used [0x00000000feab0000,0x00000000feab0000,0x0000000100000000) to space 21824K, 0% used [0x00000000fd560000,0x00000000fd560000,0x00000000feab0000) PSOldGen total 349568K, used 0K [0x00000000e0000000, 0x00000000f5560000, 0x00000000f5560000) object space 349568K, 0% used [0x00000000e0000000,0x00000000e0000000,0x00000000f5560000) PSPermGen total 26432K, used 26393K [0x00000000d0000000, 0x00000000d19d0000, 0x00000000e0000000) object space 26432K, 99% used [0x00000000d0000000,0x00000000d19c64a0,0x00000000d19d0000) 2013-05-05T23:16:10.480+0800: 5.228: [GC Desired survivor size 22347776 bytes, new threshold 7 (max 15) [PSYoungGen: 131072K->8319K(152896K)] 131072K->8319K(502464K), 0.0176346 secs] [Times: user=0.03 sys=0.00, real=0.02 secs] Heap after GC invocations=1 (full 0): PSYoungGen total 152896K, used 8319K [0x00000000f5560000, 0x0000000100000000, 0x0000000100000000) eden space 131072K, 0% used [0x00000000f5560000,0x00000000f5560000,0x00000000fd560000) from space 21824K, 38% used [0x00000000fd560000,0x00000000fdd7ff78,0x00000000feab0000) to space 21824K, 0% used [0x00000000feab0000,0x00000000feab0000,0x0000000100000000) PSOldGen total 349568K, used 0K [0x00000000e0000000, 0x00000000f5560000, 0x00000000f5560000) object space 349568K, 0% used [0x00000000e0000000,0x00000000e0000000,0x00000000f5560000) PSPermGen total 26432K, used 26393K [0x00000000d0000000, 0x00000000d19d0000, 0x00000000e0000000) object space 26432K, 99% used [0x00000000d0000000,0x00000000d19c64a0,0x00000000d19d0000) }
[0x00000000f5560000,0x00000000f5560000,0x00000000fd560000)
这种形式的日志有两种意义:
当这种日志出现在generation的详细信息里的时候,三个数字在HotSpot里分别称为low_boundary、high、high_boundary。
low_boundary: reserved space的最低地址边界;通常也跟“low”相等,这是commited space的最低地址边界
high: commited space的最高地址边界
high_boundary: reserved space的最高地址边界。
[low_boundary, high_boundary)范围内的就是reserved space,这个space的大小就是max capacity。
[low, high)范围内的就是commited space,而这个space的大小就是current capacity(当前容量),简称capacity。
capacity有可能在一对最小值和最大值之间浮动。最大值就是上面说的max capacity。
相关推荐
适用于jvm运行生成的gc日志文件可视化分析
虽然功能叫hpjmeter简单,界面也不咋地 不过容错性要比hpjmeter强很多,虽然快照中所有性能指标都挤在一起,但是很直观 总体来说比较强悍,特收金币一枚...
JVM 输出 GC 日志导致 JVM 卡住
英文版的IBM JVM GC的非常详细的技术文档,包括GC的原因分析,GC日志分析,GC过程分析
对gc日志进行统计分析,使用命令:java -jar gcviewer-1.3x.jar gc.log summary.csv [chart.png] [-t PLAIN|CSV|CSV_TS|SIMPLE|SUMMARY]
主要介绍了Java虚拟机GC日志分析,分享了相关代码示例,小编觉得还是挺不错的,具有一定借鉴价值,需要的朋友可以参考下
输出GC日志 输出 GC 日志对于跟踪分析 GC 的状况,无疑是最明显和直接的分析内存回收状况的方 法,只是 GC 日志输出后需要人肉的进行分析,来判断 GC 的状况。 JVM 支持将日志输出到控制台或指定的文件中,方法为: 1、 ...
GChisto是一款优秀的GC日志分析工具。解压后找到Chisto.jar通过命令行运行.可以对jvm的内存进行检测分析,特别针对om问题
网盘文件永久链接 目录 day1: 1 为什么要对jvm做优化 2 jvm的运行参数 3 jvm的内存模型 4 jmap的使用以及内存溢出分析 ...4 可视化GC日志分析工具 day3: 1 Tomcat8优化 2 JVM字节码 3 代码优化 .........
里面有两个 jvm的gc日志分析工具,解压后通过java -jar GChisto.jar和java -jar gcviewer-1.36-SNAPSHOT.jar的方式打开工具。
虚拟机和垃圾收集器日志分析器。 它专用于 JVM 11 及更高版本(JVM 8 支持正在开发中)。 日志必须采用适当的格式和适当的装饰器,检查最后部分的限制和工作示例。 该项目创建了两个工件: Analyzer-web.jar - 部署...
GCViewer 专业的 GC 日志分析工具, 只要安装 JDK 即可使用
- 了解下我们为什么要学习JVM优化 - 掌握jvm的运行参数以及参数的设置 - 掌握jvm的内存模型(堆内存) - 掌握jamp命令的使用以及...- 学习GC日志的可视化查看 - Tomcat8的优化 - 看懂Java底层字节码 - 编码的优化建议
该 Java 库为 Oracle JDK 1.7 和 1.8 生成的 GC 日志提供解析器。 它包括一个命令行实用程序,用于从日志生成 CSV 文件。 您可以将它们加载到您最喜欢的工具中进行分析。 请参阅以下鼓舞人心的文章作为示例 -。 要求...
GC日志可视化分析工具GC...通过GC日志可视化分析工具,我们可以很方便的看到JVM各个分代的内存使用情况、垃圾回收次数、垃圾回收的原因、垃圾回收占用的时间、吞吐量等,这些指标在我们进行JVM调优的时候是很有用的。
找到需要分析的jvm进程 3.使用jstack [pid] > /tmp/sdapjvmlog.txt导出进程的详细日志 4.使用程序打开导出的进程日志 二、此工具线程的几种状态 1.死锁,Deadlock(重点关注) 2.执行中,Runnable(重点关注) ...
NULL 博文链接:https://fs20041242.iteye.com/blog/1483944
在这个代码可以调节JVM参数,打印JVM日志,调节GC算法
1、打印GC日志 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./gc.log Tomcat则直接加在JAVA_OPTS变量里 2、分析日志得到关键性指标 3、分析GC原因,调优JVM参数
gceasy 元空间内泄露导致Full GC日志分析报告