记一次oom问题排查

大家好,我是大彬~
今天给大家分享最近出现的OOM问题。
上周五早上,测试同学反馈测试环境的子系统服务一直超时,请求没有响应。
收到这个问题之后,我有点纳闷,最近这个系统也没有改动代码逻辑,怎么会突然报服务超时的问题。为避免影响测试进度,我赶紧登陆堡垒机查看日志,看看到底啥情况。
首先先看系统负载情况,使用top命令查看。发现其中某个Java进程cpu一直持续停留在100%到200%之间。因为这个系统不涉及大量运算的逻辑,所以可以猜到要不就是死循环的问题,要不就是频繁full gc导致。
记一次oom问题排查
文章图片

查看系统日志发现,出现java.lang.OutOfMemoryError: Metaspace,很明显,元空间内存溢出了。
接着查看系统gc情况,使用以下命令查看。pid为对应的Java进程id,通过top命令获取。参数1000表示每隔1000ms打印一次记录。

jstat -gc pid 1000

一看执行结果,果不其然,full gc 从应用程序启动到采样时已经触发了几百次!这也是cpu一直100%的原因。
记一次oom问题排查
文章图片

其中还有另一个参数 MC(元空间分配内存大小),已经接近设置的最大元空间大小(配置的--XX:MaxMetaspaceSize=128m)。
这里也简单介绍下元空间。
元数据是jdk8里特有的数据结构,jdk7是叫永久代,到了jdk8永久代就废弃了,使用元空间替代。元空间被分配在本地内存中(非堆上),默认不限制内存使用,可以使用 MaxMetaspaceSize 指定最大值。
元空间由两大部分组成
  • Klass Metaspace,用来存klass的,klass是class文件在jvm里的运行时数据结构。
  • NoKlass Metaspace,专门来存klass相关的其他的内容,比如method,常量池等,这块内存是由多块内存组合起来的。
MC 就是Klass Metaspace以及NoKlass Metaspace两者总共分配的内存大小,单位是KB。上图中,MC已经接近元空间设置的上限值,也就是此时元空间内存已经不够用了,导致一直触发full gc。
然后就是dump内存进行分析,看看是什么原因导致的元空间内存溢出。使用命令./jmap -dump:live,format=b,file=/xxx 导出内存heap到xxx位置(hprof格式),然后使用MAT工具进行分析。
将hprof文件导入MAT工具,打开内存泄漏分析(涉及公司内部源码,所以打了马赛克):
记一次oom问题排查
文章图片

看到这个之后,就大概知道是什么问题了。因为最近公司内部在推广一个漏洞监控工具,需要在服务端部署agent程序,这个工具会收集、监控应用程序运行时函数执行、数据传输,可以识别常见的安全缺陷和漏洞。而打码的部分正是这个漏洞监控工具的应用包名,很可能是引入这个工具引起的问题!
进一步确认问题。打开Histogram:
记一次oom问题排查
文章图片

Shallow Heap 代表一个对象结构自身所占用的内存大小,不包括其属性引用对象所占的内存。
Retained Heap 是一个对象被 GC 回收后,可释放的内存大小,等于释放对象的 Retained Heap 中所有对象的 Shallow Heap 的和。
在Histogram视图中,选中其中一个类点击鼠标右键会弹出一个菜单,选择Merge shortest paths to GC Roots,查看当前对象到GC Root的路径,可以过滤一些类型的引用。
记一次oom问题排查
文章图片

【记一次oom问题排查】结果如下:
记一次oom问题排查
文章图片

占用内存空间最多的就是漏洞监控工具的类,也基本可以确定问题所在了。
最后把这个漏洞监控工具去掉之后,重新部署之后,就不会出现服务超时的问题了。
以上就是本期OOM问题分析的整个过程~
码字不易,如果觉得对你有帮助,可以点个赞鼓励一下!
我是程序员大彬 ,专注Java后端硬核知识分享,欢迎大家关注~
本文由博客一文多发平台 OpenWrite 发布!

    推荐阅读