1. 引子
本文介绍一下GC日志可视化分析工具GCeasy。通过GC日志可视化分析工具,我们可以很方便的看到JVM各个分代的内存使用情况、垃圾回收次数、垃圾回收的原因、垃圾回收占用的时间、吞吐量等,这些指标在我们进行JVM调优的时候是很有用的。
2. 介绍
官网地址:gceasy.io/,GCeasy是一款在线的GC日志分析器,可以通过GC日志分析进行内存泄露检测、GC暂停原因分析、JVM配置建议优化等功能,而且是可以免费使用的(有一些服务是收费的)。
打开官网后,上传日志文件,点击分析:
稍等片刻,就会展示GC日志分析后的图表了。
3. 分析
在查看图表之前,先粘贴一下我的博客应用的启动参数:
java -Xms312m -Xmx312m -XX:MetaspaceSize=768m -XX:MaxMetaspaceSize=768m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/data/blog_server/target/gc.log -jar /data/blog_server/target/blog.jar &
然后结合参数,看下该网站提供的几个分析图表。
3.1 JVM memory size
左侧表格分别展示了新生代、老年代、元数据区、汇总后的内存分配情况。其中Allocated列表示分配内存大小,Peak表示该区域内出现的最大峰值。
我们来对照一下应用启动参数:
- 新生代:启动设置了内存为312M,由于没有设置新生代在所有内存的比例值,系统会默认设置为1/3,所以312/3,近似于100M,表格中为93M。
- 老年代:老年代默认为总内存的2/3,近似于200M,表格中为208M。
- Meta Space:jdk1.8之后出现的元数据区,1.7及之前的版本只有永久代。这里展示值为768M,的确是应用启动命令中设置的值。
- 合计:这里对新生代、老年代、元数据区分配的内存进行合计。
疑问
看到这里,其实我很困惑,我的阿里云ECS服务器内存只有1个G,当前这个应用内存合计就有1个G,那我还部署了MySQL实例、Nginx实例、和一些其他应用,岂不是云服务器内存已经不够用了?
实际上在当前这套配置下,服务器上的应用都正常运行,那哪里产生了误解呢?
问题的关键就在于这个jdk1.8定义的元数据区。
我们知道在jdk1.7的时候,类的定义等信息是存储在永久区的,并且新生代、老年代、永久代都属于堆内内存,逻辑上归属于虚拟机内部的内存。
从jdk1.8开始,永久区被去掉,取而代之,用元数据区来存储类定义相关信息。并且,元数据区不再属于虚拟机堆内内存,而是直接占用操作系统上的内存,所以理论上元数据区可达到的最大内存就是操作系统的内存。
那我们应用启动参数中的-XX:MetaspaceSize=768m -XX:MaxMetaspaceSize=768m
是什么含义呢?
先说M-XX:MetaspaceSize=768m
,这个参数并不是说应用启动后马上就会分配768兆的内存给元数据区,这个数值表示的是触发Full GC的水位线。实际上,元数据区的内存大小是随着应用启动后类的不断加载从0开始慢慢增加的,如果增加到768兆触及水位线了,则会触发Full GC,对元数据区进行垃圾回收,并且元数据区内存不断加大,如果超过了MaxMetaspaceSize设置的值,则会抛出OOM异常。
所以当前这里应用元数据区占用内存大小远远不到768兆,后面我会再写一篇文章,介绍如何查看当前应用元数据区占用内存大小,这里先按下不表。
注:
另外,你可能还会有疑问,为什么这里元数据区对应的peek值是空呢?我觉得,因为当前应用的GC日志中并未出现Full GC,自然就看不到Meta data相关信息,所以GCeasy这个网站只能空着了。
3.2 Key Performance Indicators
关键性能指标:吞吐量及GC暂停平均时间、最大时间、各个时间段的比例。
我们知道,JVM GC时会暂停应用的运行,即Stop The World,简称STW。
可以看到总共发生了26次GC,其中25次暂停时间在100毫秒以内,1次暂停了160毫秒。
后面如果想调优的话,可以分析一下,如何降低GC的次数,以及时间间隔。
3.3 Interactive Graphs
以时间为维度展示的图表:
从这个图中可以看到堆内存使用过程。如果遇到内存某一时刻使用激增,触发OOM的问题,用这个图表就比较直观了。
3.4 GC Statistics
统计信息饼图:
很直观的可以看到,一次Full GC都没有触发(因为我上一节优化过了,本来还是有一次Full GC的)。
3.5 GC Causes
触发GC的原因:
这里可以看到,Allocation Failure都是新生代内存不足触发的GC,所以从这里可以看出,是否可以对此优化:加大新生代内存,从而减少GC次数。
3.5 其他
还有一些其他的功能,这里就不展示了,有需要的可以去看下。
4. 小结
看到这里,有没有觉得这个可视化网站还是很棒的,相比于直接看GC日志文件已经直观很多了。看完以后,突然觉得自己的博客应用JVM参数还有很多可调优的空间。