线上故障排查——drools规则引擎使用不当导致oom
2017-07-27 19:06
357 查看
事件回溯
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时间拉得较长,也可以退步到一个时间区间的对比)。
相关文章推荐
- Drools 规则引擎 期精华应该在于灵活配置规则信息,对于规则元数据增删不大的应用 ,但规则时常需要配置和变动的场景 ,费用适合使用
- drools规则引擎因为内存泄露导致的内存溢出
- 使用 Drools 规则引擎实现业务逻辑
- 一次线上OOM故障排查经过
- 使用 Drools 规则引擎实现业务逻辑
- Drools规则引擎的使用总结
- 使用 Drools 规则引擎实现业务逻辑
- 使用 Drools 规则引擎实现业务逻辑
- Drools 规则引擎的使用总结
- Drools 规则引擎的使用总结
- 使用规则引擎drools驱动工作流
- 使用 Drools 规则引擎实现业务逻辑,可调试drl文件
- 使用规则引擎Drools计算圆周率PI
- 使用 Drools 规则引擎实现业务逻辑
- 使用 Drools 规则引擎实现业务逻辑
- 【原创】记一次线上Tomcat故障排查-struts2 “bug”导致tomcat阻塞
- Drools 规则引擎的使用总结
- 使用 Drools 规则引擎实现业务逻辑
- 使用 Drools 规则引擎实现业务逻辑
- 使用 Drools 规则引擎实现业务逻辑