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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1347 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

第 1 条附言 · 2021-03-28 19:01:07 +08:00

感谢各位大佬支的招,问题已经找到了,有一张接近 200w 数据的表,在 2 月底一次的提交中,把之前的分页查询给去掉了,直接查了全表.

过程就是使用 mat 追踪那个 DataResultSet 对象的调用栈,最后找到了对应代码处.

感谢各位大佬.

oom

代码

回收器

对象

17 条回复 • 2021-03-28 10:32:14 +08:00

Livid

MOD

2021-03-27 12:45:59 +08:00

试试这个？

https://sentry.io/

wanguorui123

2021-03-27 12:46:58 +08:00 via iPhone

内存碎片化？

chendy

2021-03-27 13:16:52 +08:00

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

yeqizhang

2021-03-27 13:48:15 +08:00 via Android

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

specita

2021-03-27 14:05:38 +08:00

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