1、问题发现
Prometheus 报警 user-center 服务的 Old GC 过多,需要排查
2、问题分析
user-center 服务生产环境部署 4 个结点,整个堆的大小设置为 2g,新生代的大小设置为 1g。这次的报警,4 个结点都有报,查看其中一个结点发现该结点,从 10 点 30 分左右到 11 点 20 分左右,不到一个小时的时间里,竟然产生了 5 次 Full GC,这个是极其不正常的。
3、使用 GCViewer 分析 GC 日志
可以看出,整个老年代 1g 的内存,几乎已经全部被占用了,而且在 Full GC 之后,并没有回收多少内存,很显然,内存泄漏了。内存泄漏导致老年代内存空间不足,新生代的对象到了一定的年龄,需要提升,提升时发现老年代内存不够,就进行 Full GC,但每次 Full GC 之后,并没用回收多少内存,虽然并没有导致 OOM,但是很快下次提升就又需要 Full GC 了。
4、dump 堆快照文件
使用命令 jinfo -flag +HeapDumpBeforeFullGC 28679
和 jinfo -flag +HeapDumpAfterFullGC 28679
,在 Full GC 之前和 Full GC 之后 dump 堆内存快照(注意:dump 完成之后,一定要关闭这两个参数,不然频繁 Full GC 导致频繁 dump,会占用大量磁盘空间);使用命令 jinfo -flag -HeapDumpBeforeFullGC 28679
和 jinfo -flag -HeapDumpAfterFullGC 28679
关闭两个参数。其实也可以不用非要加上这两个参数然后等待 Full GC 的出现,由于是内存泄漏,老年代内存不能回收,那么直接使用命令 jmap -dump:format=b,file=before.hprof 28679
和 jmap -dump:live,format=b,file=after.hprof 28679
来 dump 堆快照文件也是可以的,加上 live 表示只保存存活对象。
5、使用 Eclipse MAT 分析对快照
很显然可以看到堆内存被对象 DoctorInvitePictureManagerImpl
占用了 811.8M,就是它导致了内存泄漏。剩下的就需要业务同学排查代码了。