运维故障分析报告【线上运行报错紧急】

分析结论

1. 接口无法连接 dubbo 注册中心，会不断重试，触发 dubbo(当前版 本:dubbo-2.5.4-SNAPSHOT-jdk1.6-8.4.jar)内存泄露 bug，导致 jvm 内存逐渐耗光， 最终内存溢出。
2. 解决方法：升级dubbo版本

说明:由于没有 dubbo 相关的源码，无法准确定位 dubbo 内存泄露原因，以上结论仅从数据 的相关性分析得出。

---

现象描述

2019年9月26日晚上，将接口从Provision-Interface里面剥离出来，单独部署在134.XXX.XXX.11，134.XXX.XXX.12，134.XXX.XXX.13，134.XXX.XXX.215，134.XXX.XXX.216，134.XXX.XXX.217这6台服务器上，当晚服务部署完毕，选址功能测试正常。

时间点	描述	备注
2019.10.09 8:50	运维群收到用户选址系统无法选址的反馈
2019.10.09 8:55	检查OMC上选址接口服务
2019.10.09 9:00	选址接口服务异常，重启OMC上选址接口服务
2019.10.09 9:05	确认问题恢复，群通知客户，客户确认系统使用恢复正常

初步分析了服务运行日志，10月9日上午7点左右有大量的FULL GC日志，其中服务异常时间段内的FULL GC特别频繁，1分钟内有50秒在执行FULL GC，而且每次FULL GC能回收的内存非常少。因为内存被消耗完，最终导致服务异常，无法提供正常的选址功能。

现场分析

现场对接口服务进行了内存监控，发现接口服务的内存呈现一个上升趋势

10月9日18:00内存采样

10月9日21:00内存采样

10月10日7:00内存采样

结合服务器运行日志，初步判断是内存泄漏导致服务异常。

分析过程

从 9 月 26 日到 10 月 9 日的服务器日志文件(catalina.out.2)分析发现，存在大量(共 98075 次)的 TimeoutException 异常，如下图

所示:

经分析确认，这部分异常是由于尝试连接 dubbo 注册中心失败导致的，由于无法连接注册 中心，dubbo 会不断重试。如下图所示：

同时，从服务器日志文件(catalina.out.2)中发现，9 月 30 日开始频繁出现“Full GC”信息:

同时，从服务器日志文件(catalina.out.2)中发现，9 月 30 日开始频繁出现“Full GC”信息:

10 月 16 日 14:00 从服务 134.XXX.XXX.13 节点获取了实时内存 dump 文件 heap.bin 进行进 一步分析，发现 com.alibaba.dubbo.common.URL 创建了 685,963 个实例，占用了约 70%的内 存(1,409,556,408/2,032,436,144=69.35%)

这部分 com.alibaba.dubbo.common.URL 对象绝大部分被 3 个线程引用: DubboClientReconnectTimer-thread-2 DubboRegistryFailedRetryTimer-thread-1 DubboClientHandler-134.XXX.XXX.149:8001-thread-120 从名称推断，这些线程和连接失败重试有关。

从对 134.XXX.XXX.13 节点的监控来看 com.alibaba.dubbo.common.URL 实例数一直持续增长:

分析工具

1. Jdk 工具包 jmap jstack
2. EclipseMAT或jvisualvm

重点说明：故障发生时可以在重启服务前通过以下命令保存现场，以方便事后分析！！！

0.获取进程pid netstat -anp|grep [port] 或者 ps -ef|grep [appname]
通过端口get pid：
通过appname get pid：1.导出虚拟机线程信息:jstack <pid>

2.导出虚拟机内存 dump:jmap -dump:live,format=b,file=heap.bin <pid>

3.根据类查看实例数:jmap -histo <pid>

4.保存服务器运行日志
例如：tomcat一般备份./logs/下面日志文件 catalina.out 如果日志有重定向按实际路径备份

5.保留业务系统报错截图或操作步骤