一次生产OOM问题排查

现象分析:
我们有一个生产服务,规模是12台机器*6个节点 = 72个节点的服务,最近老是出现某个节点突然挂掉的情况,问题出现频繁,一天需要重启很多个节点
查看tomcat日志,发现是堆内存溢出
使用jmap -heap pid查看各个JVM内存空间的使用情况发现,所有的内存都被占满了,如下图所示:
一次生产OOM问题排查
发现堆内存的确都被吃完了
使用top查看各个pid吃资源的情况后发现OOM的节点的CPU资源占用特别高,基本都在100%以上
一次生产OOM问题排查
疯狂吃CPU推断应该是在JVM在进行fullGC(回收老年代,在进行fullGC的时候,程序不提供任何其他服务),使用jstat -gc pid查看GC情况
一次生产OOM问题排查
其中每个字段的意思对应如下

S0C:第一个幸存区的大小
S1C:第二个幸存区的大小
S0U:第一个幸存区的使用大小
S1U:第二个幸存区的使用大小
EC:伊甸园区的大小
EU:伊甸园区的使用大小
OC:老年代大小
OU:老年代使用大小
MC:方法区大小
MU:方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC:年轻代垃圾回收次数
YGCT:年轻代垃圾回收消耗时间
FGC:老年代垃圾回收次数
FGCT:老年代垃圾回收消耗时间
GCT:垃圾回收消耗总时间

看到其中fullGC的次数非常高,达到200-9000次,时间高达以小时计数,所以推断应该是有大对象在内存中,并且一直在被引用

使用jmap -histo pid查看哪些对象占用了空间发现char对象占据了特别大的空间
一次生产OOM问题排查
在程序OOM的时候使用jmap -dump:live,format=b,file=tai.hprof pid这个命令dump下当时的内存文件到磁盘中。使用gzip压缩文件(VPN限速太慢,时间可能很长)并且拉去到本机上

使用eclipse的插件分析dump文件tai.hprof

发现其中一个异常,一个线程对象持有了大量内存空间
一次生产OOM问题排查
点击see stacktrace查看对应的堆栈信息
一次生产OOM问题排查
发现最后一步在程序中的堆栈信息是这一行代码是最后执行代码
一次生产OOM问题排查
查看内存占用发现一个String对象使用内存非常多,并且结构有点像第三方返回对象
一次生产OOM问题排查
将值存储到对应文件中发现这个字符串大小为660MB,其中的值截取如下:
一次生产OOM问题排查
结果:结果是发现是调用下层的Go项目返回的HTTP response中返回的对象太大,经过各种装换之后,一个线程持有的内存达到了4G多,而一个tomcat进程分配的内存总共也就5G,造成的OOM。经过排查Go项目。的确有一个地方有bug,存在笛卡尔积,在数据条数100+条列表的时候产生的对象会产生大对象的String返回到我们这个生产服务 。

上一篇:面试杂谈 - 内存泄漏如何排查


下一篇:使用JProfiler 分析 OOM