记录一次JVM调优的分析过程

线程指标数:1秒钟内 200个线程循环100次=2W请求 服务器 2核4G 场景:查询大量人脸特征数据(约10w个)

第一次压测:计划压测2分钟

JVM 参数

JAVA_OPTS="-XX:+UseParallelGC -XX:+UseParallelOldGC -Xms64m -Xmx128m -

XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -

Xloggc:…/logs/gc.log -Dcom.sun.management.jmxremote -

Dcom.sun.management.jmxremote.port=9999 -

Dcom.sun.management.jmxremote.authenticate=false -

Dcom.sun.management.jmxremote.ssl=false"

解释:ParallelGC垃圾收集器 最小堆内存 64 最大堆内存128

压测2分钟 请求没压测完毕

聚合报告

分析GC日志
查看内存使用情况 可分析出 年轻代 和老年代 都用满过 元空间有大量空闲,

查看吞吐量

26.8 很糟糕…
看GC之后的情况

发现这里有很多full GC…很糟糕

分析GC用时

发现 都是fullGC拖后腿

分析GC清除掉的内存

发现后面fullGC 基本清不掉 证明大量的内存跑老年代了.

分析年轻代

后期 清空之前和之后基本变化不大

分析老年代

也变化不大

分析元空间

发现基本就在40

分析各种GC指标图

总结分析:
发现FullGC占用时间 …接近2分钟…我压测也就2分钟…
可以得出结论.内存不够 需要加大内存…并且需要加大新生代内存 因为 是查询.查询完毕就释放掉.新生代太小会导致 新生代满了 直接进入老年代.导致清除太慢…我希望的就是 直接在新生代里就给他GC掉

第一次调优 计划压测2分钟 1分钟39秒压测完毕**

jvm参数:JAVA_OPTS="-XX:+UseParallelGC -XX:+UseParallelOldGC -Xms1024m -Xmx1024m -
XX:NewSize=512m -XX:MetaspaceSize=64m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -
XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:…/logs/gc.log -
Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -
Dcom.sun.management.jmxremote.authenticate=false -
Dcom.sun.management.jmxremote.ssl=false"
解释:相比之前 堆内存直接给1G 然后 新生代直接给512MB 元空间给64 其他不变

压测报告

吞吐量直接上来了
从7升到200
分析GC日志
先看内存使用情况

再看吞吐量

从20多变成80多 相比之下好了很多

分析GC后

发现 full gc减少了很多 只有3次

分析年轻代GC

发现基本都在年轻代回收了
证明思路是正确的

最后看统计分析图

发现 FULL GC只有2多秒钟 从原来的接近两分钟 变成了2秒钟 .效果好了很多

第二次调优:尝试用G1收集器 分析效果如何

参数
JAVA_OPTS="-XX:+UseG1GC -Xmx1024m -XX:MetaspaceSize=64m -XX:MaxGCPauseMillis=100 -
XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -
Xloggc:…/logs/gc.log -Dcom.sun.management.jmxremote -
Dcom.sun.management.jmxremote.port=9999
Dcom.sun.management.jmxremote.authenticate=false -
Dcom.sun.management.jmxremote.ssl=false"
聚合报告

2分钟没跑完

观看各项指标 发现 换了G1反而 没ParallelGC好
所以并不是根据理论说G1最屌 就G1 要根据实际压测 分析GC日志 才知道 到底用哪个好点