关于线上 oom 问题的排查,请教大佬们!

資深大佬 : killy 4

在三月中开始的时候,线上突然经常报出 oom,刚开始怀疑那几天提交的代码有问题,因为之前没有报出来过. 代码排查了几遍,没发现有什么问题. 然后把 oom 时的内存信息 dump 下来使用 jvisumalvm 进行分析,发现是 jdbc 查询时,有一个 DataResultSet 对象非常大,占用 1.9g 内存. 感觉是找到了问题的原因,但是找不到问题发生的地方,dump 下来了好几个内存快照,每次 oom 时的栈信息都不一样,但是都有这个 1.9g 的对象. 因为数据库有 600 多张表,整个系统业务很多,根本找不到是哪里查询时的占用的内存.

然后对其中一台机器尝试过进行 jvm 参数调优,调大了堆,垃圾回收器换成了 CMS+ParNew,日常这种垃圾回收器表现比未调优之前要好,但是依然报出过 oom,报 oom 那段时间一直 fgc,gc 的时间能达到三千多秒…

最后就是问题不是参数调优可以解决的,感觉就是主要找到那个大对象的代码处,进行优化. 求教各位大佬,怎么通过对象定位代码? 通过代码找感觉有点困难,因为代码非常多,整个项目启动要十分钟. 这种 DataResultSet 对象也是底层封装好的,每个查询可能都用到这个对象,现在感觉不知道从哪下手. 也想过通过数据库里面表数据的大小去反查相关代码, 找到数据库大于 1.9g 的数据表,然后着重查这几个表相关的代码,这种思路不知道行不行的通?

大佬有話說 (17)

資深大佬 : Livid

试试这个？

https://sentry.io/

資深大佬 : wanguorui123

内存碎片化？

資深大佬 : chendy

试试这个 https://www.eclipse.org/mat/
能看到大对象的引用关系，帮助定位

資深大佬 : yeqizhang

通过查那个时间点左右的查询语句是否可行？

資深大佬 : specita

如果确定是 SQL 查询的结果太大导致的，可以看一下数据库的日志，比如慢查询日志，有记录数据大小的。
或者如果用的是 druid 连接池，打开监控也能看到相关 SQL 的处理信息。
如果不是 SQL 导致的，那就是应用程序实现的问题了，可以试试用 arthas 线上排查一下。哪个请求报的 OOM 应该知道吧。

資深大佬 : Jooooooooo

能不能尝试分析下 DataResultSet 里面是什么内容.

然后再看下多次发生 oom 时间点的日志, 有没有固定的查询语句.

資深大佬 : john6lq

目测 sql 问题

資深大佬 : fantastM

是我的话，会先从慢 SQL 日志开始看起

資深大佬 : wakzz

https://wakzz.cn/2020/05/01/java/%E8%AE%B0%E4%B8%80%E6%AC%A1%E7%94%9F%E4%BA%A7%E4%BA%8B%E6%95%85OOM%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5/

資深大佬 : EminemW

jprofiler 可以看对象内容，你再到倒推出内容存在那张数据库表？

資深大佬 : ychost

估计是 SQL 的问题

資深大佬 : lewis89

找到泄漏点的数据结构通常是 GCRoots，
然后升级一下依赖的版本看看之前的依赖版本 release log 里面是不是有解决 OOM 的问题

資深大佬 : lewis89

你能确认 DataResultSet 就是 GCRoots?

資深大佬 : lewis89

像 OOM 这种问题用 MAT 分析一下基本上就能定位到泄漏点了，然后上网找找是不是有类似的泄漏情况，找不到最后再去处理，一般泄漏点都是框架的代码，业务仔自己 new 的对象一般活不过两轮 GC

資深大佬 : xuanbg

在内存里面找到了 1.9G 的对象，就猜不出是哪张表的数据？找到表就能找到读数据的代码。

資深大佬 : securityCoding

按我的经验来看 mat 导进去，一般就能准确定位到内存泄漏代码了

資深大佬 : wapzjn

我想起了以前一个同事调用别人接口忘记了传递分页信息，正好接口的开发同事也没有处理没有分页信息时的场景，然后用户一查询 OOM