前言
前一段时间,公司同事的一个线上服务OOM
的问题,我觉得挺有意思的,在这里跟大家一起分享一下。
我当时其实也参与了一部分问题的定位。
1 案发现场
他们有个mq
消费者服务,在某一天下午,出现OOM
了,导致服务直接挂掉。
当时我们收到了很多内存
的报警邮件
。
发现问题之后,运维第一时间,帮他们dump了当时的内存快照,以便于开发人员好定位问题。
之后,运维重启了该服务,系统暂时恢复了正常。
大家都知道,如果出现了线上OOM问题,为了不影响用户的正常使用,最快的解决办法就是重启服务。
但重启服务治标不治本,只能临时解决一下问题,如果不找到真正的原因,难免下次在某个不经意的时间点,又会出现OOM问题。
所以,有必要定位一下具体原因。
2 初步定位问题
当时运维dump
下来的内存快照
文件有3G
多,太大了,由于公司内网限制,没办法及时给到开发这边。
没办法,只能先从日志文件下手了。
在查日志之前,我们先查看了prometheus
上的服务监控。查到了当时那个mq消费者服务的内存使用情况,该服务的内存使用率一直都比较平稳,从2022-09-26 14:16:29
开始,出现了一个明显的内存飙升情况