MAT分析线上OOM实例

一问题

群里小伙伴说发生oom了。我没有那台机器权限，先保留现场，找人生成dump文件（jmap -dump:format=b,file=heapDump  XXXX）是对应的进程id。然后重启。当然生成文件较大，2.4G 需要一段时间，会造成一次FullGC。非紧急时刻业务高峰期慎用。

  当然更推荐一种在启动脚本就加上配置：-XX:+HeapDumpOnOutOfMemoryError 这样发生OOM就不用再手动生成了。

  紧急排查问题，jmap -histo:live 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀

看下前10的也大概能有助于锁定范围。比如这个就是一个自定义的业务bean entity很多，74W条。

二 mat 分析

mat 还是很强大的。

打开文件后，提示错误。

这个不是文件不完整，是我本地电脑内存不够了，因为mat默认的是1024M.这个文件就2G多了，还要分析，所以改为-Xmx3072m 就ok了。

总体视图：

2G内存，这个jdbc的结果集就占了1.4G，70%的占用，因此强烈关注与此。

2 histogram: 这个一开始看class的实例数目,内存占用差不多，内容更详细，objects是数量，shallow heap 是本身占用大小，retained heap是实际加上引用占用大小。

看这个基本上就能找方向，结果集及对应的entity可能有问题。

继续看占用最大的结果集是啥？

dominator:List the biggest objects and what they keep alive.

知道对应的结果集内容，跟entity想匹配。单条数据在1.5K左右。

看完这些总体的，改看下具体的原因。mat会给出可疑的分析：

这里就是发生oom对应的线程，看线程的详细信息：

内部RPC框架，可以一层层的看到调用关系，其中dao层可以看到SQL。

select * from table where user_id=?

这里有个插曲，没看到sql之前，我就猜想应该根据条件查询没有limit导致的。

但是这个sql有条件，我强烈怀疑某个id有大量的数据几W那种。

工程是别人的，业务也不懂，小伙伴说没有多条，都是一对一的。

被否定了，可是这100多W条的restset怎么来的呢？难道是一直反复查询不释放。

在找人看看发生oom的日志，上下文无有效信息。

没招了，看阿里云的数据库监控吧，看看有没有慢sql或者之前的那种jdbc连接数过多那种。

真的有，时间点与sql匹配的上，参数是0.执行了1g秒却没有提示慢SQL，返回是1.7m就是170W，跟结果集的169W对应。

问下业务的同学，原来0是特殊情况，历史的数据100多W这种默认为0 的。

至此，确认无疑。因为是偶发的调用，所以问题出现频率不高，但是一旦查询返回结果集过大，则会爆掉。

三 改进

要了对应工程git权限，看下这块代码。

也是祖传代码，维护的同学表示无辜。看下逻辑，还是取一条。

那就改下SQL 加上limit 1吧。

反思：对于帮忙排查问题，面临的是机器，代码都不熟悉的情况，需要对应的业务同学帮忙确认问题，但是又不能全信。因为他说的是正常的业务流程，对于极端的异常情况是没有考虑到的。