记一次java程序假死的处理过程(JVM参数调优)

前景提要
休假的时候生产服务器出现了一次假死,现象是外部无法访问,批处理任务也不再运行,由于当时不在现场,客户直接kill了进程,导致没法对现场日志或者现场情况进行采集。
赶回公司后它们重启已解决问题,但是领导对这次事件反应非常强烈,要求必须查明原因,一头雾水的我就开始了这填坑之路。
填坑历程
由于缺失现场一手资料,只能靠他们描述的现象对事故现象进行模拟,虽然一波三折,但是最终还是在50线程每秒5次并发的情况下复现了该场景。
压测的堆内存图如下:
在这里插入图片描述
老年代内存图如下:
在这里插入图片描述
1、压测过程中我发现老年代内存线性上涨,一开始以为是内存泄露导致内存溢出,但是查看日志发现直到系统假死并没有相关错误输出,于是突然灵光一现,注意到系统在假死前有过一次fullgc,gc后内存占用明显降低,这个时候基本上可以排除内存泄露的原因了(内存泄露是因为回收不了);
2、那么就要着手其他因素,这个时候我注意到压力测试仅仅进行了十分种,但是ygc次数有一万多次,明显有过于频繁的回收发生,回去查看jvm的参数配置,整个堆大小有2g,但是年轻代仅仅分配了256m,我们处理的业务流程比较长,平均时间在1s左右,那么这个时候就会导致一秒内多次gc不掉的对象会被放入幸存区,再次查看幸存区大小,发现仅有可怜的20m,这就导致在高并发情况下会进行高频率的年轻代回收,在请求的生命周期还未结束前就已经达到放入老年代的条件,这个时候就会导致老年代内存直线上升。
3、如上分析已基本找到问题所在,但是没有明确为什么FullGC会导致应用假死,经过一番推论和查证,最终在GC日志中找到了下面的信息;
在这里插入图片描述
原来是因为上线时没有针对业务特点进行JVM参数的调整,配置的JVM新生代空间太小引起YGC触发频率过高,从而大量短生命周期的对象过早进入老年代,老年代内存占用随时间直线上升,进而引起触发FullGc,特别的,在未指定FullGC触发节点的情况下,JVM预留内存空间不足以满足客户请求的内存需求时,在某次YGC时因为servivor空间不足先触发了promot failure,接着想放到Old区时发现就触发了concurrent mode failure,此时JVM启动备案操作,临时启动SerialOld收集器来重新进行老年代垃圾回收,引起Stop World Time,应用假死;
解决方案
1、修改-Xmn为-Xmx一半大小(根据业务及项目情况调整);
2、添加XX:SurvivorRatio=8(根据内存变化调整:若老年代依旧持续增长,则可调低该参数)
3、修改Xloggc:路径为可用路径;(由于之前没检查该路径,一直没有生成该文件,给排查问题带来极大不便)
4、添加-XX:+UseCMSInitiatingOccupancyOnly 指定触发条件只有用户指定
5、添加-XX:CMSInitiatingOccupancyFraction=80 指定老年代内存占用达到80%触发CMS
6、添加-XX:+CMSScavengeBeforeRemark (FullGC前先进行YGC)
7、一个可选参数(-XX:+CMSParallelRemarkEnabled)开启并行重标记
修改后
同样的测试条件下,堆内存图如下,老年代几乎无增长,证明参数修改有效。同时,由于青年代垃圾回收占用CPU资源的释放,压力测试tps上升20%左右
在这里插入图片描述

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页