2020年12月8号营销mrc应用内存突然上涨并导致系统OOM

背景

12.08号中午营销mrc应用突然出现内存持续上涨，由开始的67%上升到85%左右（监控如下），好在上升过程比较慢，果断地重启解决了问题。解决问题和分析问题的过程如下。

解决问题过程

mrc是营销的底层应用，主要偏规则计算，共6台机器（2个集群下，且集群流量是相互隔离的，如上层hipc集群的流量不会请求到k8s集群机器），6台机器同时内存持续上升，参考示意图一。

因当天中午是大促，考虑到一个集群下只有3台机器，怕重启一台过程中，其他两台承受不住大促的流量，开始不敢考虑进行单台重启，经过短时间决策考虑到每台的cpu只有5%左右，最坏的担心是内存可能一下子吃不消，如频繁gc等可能会影响正常流量的访问，于是做最坏的打算：果断进行重启（重启之前进行流量摘除，同时dump内存进行后续分析），结果是没有任何问题出现，参考示意图二。整个处理问题的详细流程如下：

1. 目标重启机器进行流量摘除，调节重启机器的dubbo权重为0即可，由于dump内存过程是耗费内存的操作，服务器可能出现假死现象影响正常调用，所以需要流量摘除。
2. 强制对目标重启机器进行一次full gc，目的是为了回收掉正常的内存对象占用，防止正常内存占用和真正有内存泄露的对象影响，影响分析，可采用以下命令：
3. dump下目标机器内存，命令如下：

jmap -histo:live 13  （触发full gc）
 或
jmap -dump:live,file=dump_001.bin 13  （触发full gc，触发后把dump_001.bin文件删除）
或
jcmd 13 GC.run  （触发young gc)

4. 使用IBMAnalyzer（或者jdk自带的 jvisualvm 工具或者mat工具）对dump文件进行分析即可

 jmap -dump:format=b,file=dumpFile 13

事后对最好的方案是同运维新增一台mrc机器，然后再进行每一台进行重启，参考示意图三。

事后分析

事后对dump文件进行分析，由于涉及到具体业务不再详述，只描述一下结论：因为当天mrc配置了影子库导致。根源由于druid存在监听影子库配置的线程不会随着压测的结束而退出，在mrc进行压测后没有重启的情况下触发不断创建线程，导致mrc应用内存不断上涨。