记一次oom问题排查-蒲公英云

记一次oom问题排查

大家好，我是大彬~

今天给大家分享最近出现的OOM问题。

上周五早上，测试同学反馈测试环境的子系统服务一直超时，请求没有响应。

收到这个问题之后，我有点纳闷，最近这个系统也没有改动代码逻辑，怎么会突然报服务超时的问题。为避免影响测试进度，我赶紧登陆堡垒机查看日志，看看到底啥情况。

首先先看系统负载情况，使用top命令查看。发现其中某个Java进程cpu一直持续停留在100%到200%之间。因为这个系统不涉及大量运算的逻辑，所以可以猜到要不就是死循环的问题，要不就是频繁full gc导致。

查看系统日志发现，出现java.lang.OutOfMemoryError: Metaspace，很明显，元空间内存溢出了。

接着查看系统gc情况，使用以下命令查看。pid为对应的Java进程id，通过top命令获取。参数1000表示每隔1000ms打印一次记录。

jstat -gc pid 1000

一看执行结果，果不其然，full gc 从应用程序启动到采样时已经触发了几百次！这也是cpu一直100%的原因。

其中还有另一个参数 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工具，打开内存泄漏分析（涉及公司内部源码，所以打了马赛克）：