线上故障排查——drools规则引擎使用不当导致oom

事件回溯

1、7月26日上午11:34,告警邮件提示:tomcat内存使用率连续多次超过90%;

2、开发人员介入排查问题,11:40定位到存在oom问题,申请运维拉取线上tomcat 内存快照dump;

3、开发人员担心服务抗不过下午的业务高峰期,让运维在中午低谷期间重启tomcat;

4、11:45,运维人员重启tomcat,内存使用回落。

事件分析

1、根据监控历史数据,发现7月10日后,内存逐步上升,且不能被full GC;怀疑和前一周版本有关,但检查前一周版本内容,不可能导致omm;

2、拿到线上dump文件分析,发现drools规则引擎相关对象占据了90%的内存,初步断定和drools的使用有关;

3、走读代码和drools的使用手册,发现使用不当:在使用完drool的fact对象后,未能及时释放,导致对象无法回收;

4、再回溯drools使用业务场景为当前app版本的新功能提供服务,新版本刚好在7月10日左右发布市场,所以,内存飙高最先出现在7月10日。

整个现象解释通畅。

问题修复

1、在本地环境压力测试模拟线上情况,重现oom;

2、更改drools相关使用代码,加上资源释放逻辑。

更改前:

{

.......

kSession.insert(fact);
kSession.fireAllRules();

.......

}

  

更改后:

{

.......

FactHandle handle = kSession.insert(fact);
kSession.fireAllRules();
kSession.delete(handle);

........

}

  

3、更改后,再次压测,问题修复。

总结

1、引入第三方jar时,核心功能一定要做压力测试,模拟线上真实高并发场景,检查是否存在并发问题或者omm问题;

2、使用第三方jar时,一定参考官方的资料或者demo做开发,切不可轻信网上随意搜索得来的二手资料;

3、oom的现象:jvm内存使用不断上升,且不能被full GC掉;正常情况下jvm内存使用曲线是平缓的锯齿状,而oom的内存使用曲线上升趋势的锯齿状,如下:

 

线左边为正常状态,线右边为oom时。

4、oom确认手段:jvm内存dump分析:

    • 查看内存占用最大的对象,并据此找到泄露点;
    • 间隔两个full gc区间各拉一个dump,并比对这个时间段内增加的最多的对象,据此找到泄露点。(可能两次full gc时间拉得较长,也可以退步到一个时间区间的对比)。
posted @ 2017-07-27 19:06  倒骑的驴  阅读(4340)  评论(0编辑  收藏  举报