一次生产OOM问题排查

2020-05-24 12:04:52 阅读：230 来源： 互联网

现象分析：
我们有一个生产服务，规模是12台机器*6个节点 = 72个节点的服务，最近老是出现某个节点突然挂掉的情况，问题出现频繁，一天需要重启很多个节点
查看tomcat日志，发现是堆内存溢出
使用jmap -heap pid查看各个JVM内存空间的使用情况发现，所有的内存都被占满了，如下图所示：
在这里插入图片描述
发现堆内存的确都被吃完了
使用top查看各个pid吃资源的情况后发现OOM的节点的CPU资源占用特别高，基本都在100%以上

疯狂吃CPU推断应该是在JVM在进行fullGC(回收老年代，在进行fullGC的时候，程序不提供任何其他服务)，使用jstat -gc pid查看GC情况
在这里插入图片描述
其中每个字段的意思对应如下

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的时候使用jmap -dump:live,format=b,file=tai.hprof pid这个命令dump下当时的内存文件到磁盘中。使用gzip压缩文件（VPN限速太慢，时间可能很长）并且拉去到本机上

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

发现其中一个异常，一个线程对象持有了大量内存空间
在这里插入图片描述
点击see stacktrace查看对应的堆栈信息

发现最后一步在程序中的堆栈信息是这一行代码是最后执行代码

查看内存占用发现一个String对象使用内存非常多，并且结构有点像第三方返回对象

将值存储到对应文件中发现这个字符串大小为660MB，其中的值截取如下：
在这里插入图片描述
结果：结果是发现是调用下层的Go项目返回的HTTP response中返回的对象太大，经过各种装换之后，一个线程持有的内存达到了4G多，而一个tomcat进程分配的内存总共也就5G，造成的OOM。经过排查Go项目。的确有一个地方有bug，存在笛卡尔积，在数据条数100+条列表的时候产生的对象会产生大对象的String返回到我们这个生产服务。

标签：一次,查看,OOM,pid,排查,对象,内存,使用,大小
来源： https://blog.csdn.net/jiexiu4617/article/details/106303244

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

一次生产OOM问题排查