JVM 频繁GC快速排查捷径

大家好,分享一个线上GC案例,相信会对大家有所帮助。

本人曾任职于阿里,每日优鲜等互联网公司,任技术总监。

在分享案例前,先聊聊哪些场景会导致频繁full gc:

    1,内存泄漏(代码有问题,对象引用没及时释放,导致对象不能及时回收)

    2,死循环

    3,大对象

    尤其是大对象,80%以上的情况就是他。


那么大对象从哪里来的呢?

1,数据库(包括mongodb等nosql数据库),结果集太大

2,第三方接口传输的大对象

3,消息队列,消息太大

根据多年一线互联网经验,绝大部分情况是数据库大结果集导致。

好,现在我们开始介绍这次线上故障:

在没有任何发布的情况下,pop服务突然开始疯狂full gc,观察堆内存监控没内存泄漏,回滚到前一版本,问题仍然存在。

按照常规做法,一般先用jmap导出堆内存快照(jmap -dump:format=b,file=文件名 [pid]),然后用mat等工具分析出什么对象占用了大量空间,再查看相关引用找到问题代码。这种方式定位问题周期会比较长,如果是关键服务,长时间不能定位解决问题,影响太大。

下面来看看我们的做法,我先安排一个架构师按照常规做法分析堆内存快照。与此同时另外的同学去查看数据库网络IO监控,如果网络IO有明显上升,并且时间点吻合,基本可以确定是大结果集导致了full gc,赶紧找DBA快速定位大SQL(对DBA来说很简单,分分钟搞定,如果DBA不知道怎么定位,那他要被开除了,哈哈),定位到sql后再定位代码就非常简单了。原来是一个接口有个必传的参数没传,也没加校验,导致sql语句where后面少了一个条件,一次查几万条记录出来,真坑啊!

这种方法是不是要快很多,哈哈,5分钟搞定。

欢迎关注个人微信公众号:架构师进阶之路


作者简介:15年电商研发经历,曾任职于阿里巴巴,楚楚街,每日优鲜等公司,任技术总监。个人微信公众号:架构师进阶之路

你可能感兴趣的:(JVM 频繁GC快速排查捷径)