JVM性能调优实战

《JVM常见参数及命令》

https://github.com/dvomu/document/tree/main/blog_doc/jvm
下载后放到服务器目录：apache-tomcat-8.5.34/webapps/ROOT
手动解压并删除war包

jar -xf gc-test.war
rm -rf gc-test.war

gc-test.war项目实现的功能:
读取电影文件movies.dat，载入到内存 查询电影数据时，随机返回1w ~ 10W个数据。每次请求随机取前10条数据返回。

http://192.168.88.101/movie/query
可以获取到数据即部署成功

https://jmeter.apache.org/download_jmeter.cgi
本文使用的JMeter 5.4.3版本。
修改jmeter/bin/jmeter.sh（Windows 改 jmeter.bat）文件:

# 最大内存增加到4G
set HEAP=-Xms1g -Xmx4g -XX:MaxMetaspaceSize=512m

GCeasy分析，GCeasy是在线免费分析工具，也可以使用GCViewer离线分析，推荐使用GCeasy。
关键指标

解读

• 吞吐量：18.285%
• STW平均时间：96.6毫秒
• STW运行最大时间：320毫秒

GC之后数据分析

GC 持续时间

GC回收内存情况

Young GC 回收情况

Meta Space情况
Meta Space基本没有太大变化

数据分布情况

Minor GC清理掉的垃圾对象合计17.72gb，说明产生的临时对象非常的多
Minor GC的执行间隔为1044ms，说明发生gc的行为是比较频繁的
Full GC发生了1284次，非常频繁
Full GC的平均持续时间为167ms，时间较长 GC的暂停次数为2328次，暂停次数将影响到服务的响应时间

2.4 测试结论

基于上面报告分析结果，我们可以发现：

• 年轻代与老年代在高峰时，基本将可用空间都占满了，说明内存空间不足，需要调整内存大小。
• 整个测试系统吞吐量并不高，最大停顿时间较长，平均停顿时间较长。
• full gc的时间要远高于younggc的时间，在调优时应当尽量的减少full gc。
• 从老年代的gc情况来看，gc之前与之后的差并不大，说明老年代的垃圾对象并不是很多。
• Meta Space空间充足，基本没有变化，占用空间40m左右。
• 大部分发生gc的原因都为分配失败，也就说内存不足导致

3 第二次测试（PS + PO + 加内存）

3.1 配置调整

在jvm调优中，调整内存大小是调优手段中最为基本的一种手段，但是需要注意的是，内存的调整并不是简单的加大内存，而是需要结合业务特性、gc类型等内容进行调整。
对于我们目前测试的应用而言，属于及时响应、低延迟的应用，这样的应用在jvm堆内存中，对象的存活时间较短，所以应该将年轻代的内存调大些。

 #设置堆内存为1024m 
 #设置年轻代大小为512m，默认是堆内存的1/3 
 #设置初始的Metaspace大小为64m
#使用时去掉换行
 JAVA_OPTS="-XX:+UseParallelGC -XX:+UseParallelOldGC -Xms1024m -Xmx1024m 
 -XX:NewSize=512m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
 -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:/var/log/gc.log 
 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 
 -Dcom.sun.management.jmxremote.authenticate=false 
 -Dcom.sun.management.jmxremote.ssl=false"

重新Tomcat后重新压测

3.2 开始压测

测试线程数不变。
统计垃圾回收情况

FullGC次数明显有下降

查看聚合报告

系统吞吐量也有明显提升，系统异常率彻底没有了。

3.3 gc 日志分析

吞吐量与停顿时间都有明显的提升。

项目启动前有两次FullGC应该是之前堆中存储的数据，在系统运行到中途的时候发生过一次FullGC，并且内存释放效果非常明显。

GC持续时间大部分都在200毫秒内，包括FullGC。

Full GC总共发生了3次，Minor GC的次数明显下降。情况有了很大的改善。
在对象的统计中，可以看出对象的平均生成率:495.72m/s，平均的晋升率:6.71mb/s。

3.4 测试结论

总体来讲，通过调整内存大小，对于服务的性能有了显著的提升。 下面尝试下将垃圾回收器更换成G1，看下表现怎么样?

4 第三次测试（G1）

选择性能更优的垃圾收集器也是调优的手段之一，在jdk8中，使用率最高的当属G1收集器了，下面我们就尝试切换成G1收集器，来看下它的表现。

4.1 配置情况

#使用时去掉换行
JAVA_OPTS="-XX:+UseG1GC -Xmx1024m -XX:MetaspaceSize=64m 
-XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
-XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:/var/log/gc.log 
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false"
 

按照上面配置，目前配置情况是

• 垃圾收集器G1
• 内存分配1024m
• 停顿时间100毫秒
• 并发量200线程执行100次，共20000次请求

4.2 开始压测

统计垃圾回收情况

FullGC没有出现过。

查看聚合报告

这个结果要比同等内存大小的ParallelGC性能稍好一些，但是提升并不明显。

4.3 gc 日志分析

停顿时间有了几倍的提升。

GC清理后内存释放空间也比较明显。

大多数的Young GC时间在100毫秒，小部分在200毫秒左右，没有发生FullGC 的情况。

4.4 测试结论

更换G1垃圾收集器后，其性能有所提升，如果在大内存的情况下效果会更好。原因是：G1垃圾收集器适合大内存低延迟的场景，比如设置6G、8G内存的场景下保持低延迟。

5 第四次测试（ZGC）

下面我们将垃圾收集器换成ZGC，需要注意的时，jdk需要切换到jdk11版本。

5.1 配置情况

修改配置

 #使用时去掉换行
 JAVA_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx1024m
-XX:MetaspaceSize=64m -Xlog:gc*:/var/log/gc.log -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9999 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false"

按照上面配置，目前配置情况是

• jdk11
• 垃圾收集器ZGC
• 内存分配1024m
• 并发量200线程执行100次，共20000次请求

5.2 开始测试

查看GC统计

ZGC中没有分区的概念，也没有youngGC FullGC。
查看聚合报告

吞吐量明显变小了，可能是因为ZGC适合更大的内存，在小内存上发挥不了它的优势。

5.3 gc 日志分析

从报告上看，吞吐量百分比、STW平均时间、STW运行最大时间确实有明显的提升。

垃圾回收时间都在10毫秒，这是数据和官方宣称的比较吻合。

每次GC清理释放的内存空间，大多数GC清理所释放的内存都不多。

GC次数和前面几个也差不多，没有次数上的差异。

5.4 测试结论

在ZGC方面的表现，无论是吞吐量还是停顿时间均有不俗的表现。 综合起来看的话，ZGC的表现还是很不错的，如果给其设置大内存，依然可以得到较短的停顿时间。

6 总结

对于JVM的调优，给出大家几条建议:

• 生产环境的JVM一定要进行参数设定，不能全部默认上生产。
• 对于参数的设定，不能拍脑袋，需要通过实际并发情况或压力测试得出结论。
• 对于内存中对象临时存在居多的情况，将年轻代调大一些。如果是G1或ZGC，不需要设定。
• 仔细分析GCeasy给出的报告，从中分析原因，找出问题。
• 对于低延迟的应用建议使用G1或ZGC垃圾收集器。
• 不要将焦点全部聚焦jvm参数上，影响性能的因素有很多，比如:操作系统、tomcat本身的参数等。