jvm学习——实际项目调优

jvm学习——实际项目调优

Scroll Down

1.原项目未进行gc调优

发送了4000次yonggc 和80多次的full gc 停顿时间达到45秒

1.和配置gc参数

选用CMS垃圾处理器,并配置堆内存

2.修改日志输出等级

观察到生产环境日志的输出等级为info修改为error

log4j.logger.p6spy=info,stdout,spyFile

级别info修改为error

log4j.logger.p6spy=error,stdout,spyFile​

效果不明显
image.png

3.增大初始堆内存大小

修改堆内存大小,将最小堆内存与最大堆内存调整一致。
image.png

4.dump堆内存分析

总共dump了三天的日志,查看是否发生内存泄漏,使用mat进行内存分析。
使用包的形式分析类,横向对比两天的对象变化
image.png
定位代码:
image.png
image.png
查看代码,发现公司的产品的这三个对象都是进行了json的转换,而使用的是GSONutils,发现里面的json转换有问题
image.png
每次都是new一个新的GSON对象进行转换,可能导致问题出现
image.png
这个待测试

2.待调整

这台服务器的访问量是最大的,而且访问次数最多的服务器,待申请进行调整
image.png
image.png

3.yonggc次数多

堆内存信息查看
image.png
gc时间查看
image.png
调整参数

-XX:CMSInitiatingOccupancyFraction=70  使用cms作为垃圾回收使用70%后开始CMS收集

调整70 80的区别
image.png

-XX:+UseParNewGC ## 对年轻代采用多线程并行回收,这样收得快
-XX:+UseCMSCompactAtFullCollection  在FULL GC的时候对年老代的压缩,Full GC后会进行内存碎片整理,过程无法并发,空间碎片问题没有了,但提顿时间不得不变长了

image.png

image.png
image.png
image.png

set JAVA_OPTS=-Xms1024m -Xmx1024m -XX:MetaspaceSize=2048m -XX:MaxMetaspaceSize=2048m -XX:+UseConcMarkSweepGC -XX:SurvivorRatio=8 -XX:CMSInitiatingOccupancyFraction=70 -XX:CMSFullGCsBeforeCompaction=3 -XX:+UseCMSCompactAtFullCollection -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:D:/成都局项目/gc/gc.log

image.png