为了账号安全,请及时绑定邮箱和手机立即绑定

平时的一些trouble-shooting-定时任务执行时,服务器load过高

2017.04.17 23:46 13789浏览
现象

某服务在后半夜2点执行的定时任务报警,执行失败,并且load升高报警。

监控

检查了监控,包括cpu、网卡流量、TCP连接数等都没任何异常

内存泄漏

分析gc日志,发现在执行期间频繁执行fullgc,但是heap区没有变小。

检查jvm内存

当时在load过高时,保存了两份内存文件,一份是原始的,一份是fullgc之后的存活的。进行对比。

原始内存

图片描述

fullgc之后存活的内存

图片描述

可以看出来在fullgc之后的其实内存没有变化,并且蓝色的区域已经沾满了3.5G,已经是整个的93.84%。

图片描述

分析内存中的对象,发现在出问题的线程中。发现里面最大的hashmap存的是XXResult对象,并且这个hashmap占了整个的71.3%。

分析代码原因

在代码中找到具体的这个对象组装的位置,发现是因为请求量过大,没有对List进行分页处理。导致这个Map越来越大,并且只有这个定时任务执行完毕,这个最大的对象才会被回收,因为一直有引用。

解决问题

foreach循环里使用的业务对象进行分页,进行批量处理,把声明放到foreach循环内,在分批处理之后,之前new出来的对象自然会被回收。

线上发布验证

定时任务执行时间缩短,load正常,问题解决。

点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

18人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 邀请有奖 帮助中心 APP下载
官方微信

举报

0/150
提交
取消