你的位置:首页 > Java教程

[Java教程]记一次JVM调优之旅(斗争full gc)


俗话说技多不压身,当年苦读《深入理解JVM》还专门整理了笔记,现在就用上了~

笔记 http://www.cnblogs.com/syjkfind/p/3901774.html

【症状】 用户操作数据导出时总会发生卡顿,后台占内存的定时任务发生时也会。JVM参数就不贴了,比较普通且相对合理。

【思路】

查gc日志是发生了full gc,tomcat日志零零散散有很多exception。

另外凭着对代码的了解,触发时同时刻的日志显示正在执行较大数据量的查询而且装载进JVM,方法调用和临时变量也很多。

【分析】

1.minor gc很频繁,但时间短所以问题不大,触发原因基本都是申请空间失败。

2.偶尔有System.gc(),时间大概1分钟。代码中没有显式调用,基本确定是监控程序RMI访问触发的。可以加参数禁用 -XX:+DisableExplicitGC 。

3.时常有promotion failed,即在minor gc时年轻代的存活区空间不足而进入老年代,老年代又空间不足而触发full gc。时间大概3分钟。解决思路一种是增大存活区,一种则相反是去掉存活区增大老年代。相关参数一般有:

-XX:SurvivorRatio=32 存活区除以伊甸区的比率,存活区有from和to两个,所以这里的意思是单个存活区占年轻代的1/34;

-XX:OldSize=60M 老年代大小;

-XX:MaxTenuringThreshold=15 即多少次minor gc后存活的年轻代对象会晋升老年代。

4.经常有concurrent mode failure,即CMS执行过程中老年代空间不足,这时会变成Serial Old收集器导致更长时间的停顿。时间大概5分钟。其中引发这一问题的情况可能是浮动垃圾太多、可能是CMS收集器本身也占用堆空间、也可能是老年代太多碎片,但都是CMS收集器的特性导致的。相关配置一般有:

-XX:CMSInitiatingOccupancyFraction=80 即老年代满80%时触发CMS(full gc),调高则full gc相对减少,调低则full gc处理得比较快;

-XX:UseCMSCompactAtFullCollection 或 -XX:CMSFullGCsBeforeCompaction=5 即full gc前或后做碎片整理。

5.另有个有趣的文章,过多过长的exception会导致promotion failed

http://www.th7.cn/Program/java/201511/685711.shtml

可能挺符合我们的场景的,没有运维权限,下次可以考虑找运维dump个分析一下对象。

以前为了追踪错误关闭了“快抛” -XX:-OmitStackTraceInFastThrow 即反复出现的exception不会用一个静态的没堆栈信息的实例去代替,这个要权衡一下了。

【解决】

创建很多对象占了年轻代?大对象导致占满老年代?浮动垃圾(CMS时继续在产生临时对象)或老年代碎片?

调优多少是可以改善的,但似乎代码本身更有问题,恐怕分配再多的内存都不够吃。比如没有应用较完善的一级缓存二级缓存,比如经常粗暴地把上万条记录加载进来,还没做分页,还有藏的比较深的做了切面触发异步服务把异步服务队列占满了。初期享受了框架的便利而考虑设计的少,而现在则要开始还技术债务了~

所幸的是在有限的时间里,我们有简单粗暴有效的方法缓解这些问题:加服务器,把大任务剥离出来~

而中长期的考虑来看,在不改变现有框架的前提下,整改exception、整改业务代码做分页、封装数据库分页查询框架、改造数据库层二级缓存(集群范围内缓存)会是比较有效的措施。

更长远的肯定就是回归Spring系主流框架,再者进军服务化了。。。但那个几乎要把业务代码重新写一遍,是后话了。

回归主题如果是调优来解决问题,最好是dump了做更深入的分析。主观上看来启用快抛、gc后碎片整理、增大存活区应该是比较有针对性的调整,而CMSInitiatingOccupancyFraction取值和CMS各阶段细致的配置则需要更量化的分析。