一次线上生产系统内存泄漏排查与优化实践

石杉的架构笔记

已于 2022-03-16 21:23:26 修改

阅读量505

点赞数 3

分类专栏： JVM OOM 内存泄漏文章标签：内存泄漏 JVM OOM Java Dubbo

于 2022-03-16 18:54:25 首次发布

本文链接：https://blog.csdn.net/qq_42046105/article/details/123533146

版权

本文分享了一次基于Dubbo的线上系统因内存泄漏导致的OOM故障排查及优化过程。在系统B大规模更新后，系统A的JVM内存使用率飙升并触发OOM。通过排查，发现是由于Dubbo框架在服务更新时创建大量无法回收的对象，导致内存泄漏。解决方案是设置系统B的dubbo protocol协议，避免创建无用对象。

摘要由CSDN通过智能技术生成

今天给大家分享一个我们之前基于dubbo开发一个线上系统时候遇到的内存泄漏生产问题的排查与优化实践经验，相信对于大家多看一些类似的案例，以后对于大家自己在线上系统遇到各种生产问题的时候，进行排查和优化的思路会有很大的启发。

内存泄漏问题发生背景原因

先给大家简单说一下这个内存泄漏问题的发生背景，线上生产环境部署了两个系统，我们可以认为是系统A和系统B，同时系统B因为是大流量核心系统，所以部署了几十台机器，定位就是集群部署要抗每秒几万的TPS的，两台系统之间是基于dubbo作为rpc调用框架，注册中心用的是zookeeper，如下图所示。
在这里插入图片描述
在这个背景之下，某一天系统B因为更新了代码，因此发起了一次几十台机器的全量滚动更新和部署，也就是说，系统B的开发团队基于最新的代码把几十台机器依次用最新代码重新部署了一遍，也就是每台机器都会有一次系统停止和重启的过程，如下图所示。
在这里插入图片描述
没想到生产环境的灾难性故障就这么突然发生了，在系统B的几十台机器依次重新部署之后，结果系统A的开发团队惊讶的发现自己的系统居然过了一会就发送了JVM内存使用率飙升超过90%的告警，而且很快系统A居然就直接OOM内存溢出崩溃了，如下图所示。
在这里插入图片描述
于是系统B的开发团队顺利的把一个大版本更新了几十台机器之后，心满意足的欣赏自己的成果呢，系统A的开发团队突然开始一脸懵逼的手忙脚乱进行了生产故障的排查。那么大家可以想想，这个时候，如果是你负责的线上系统突然给你发送内存使用率飙升超过90%，而且很快就OOM内存溢出，你会怎么排查？