共计 930 个字符，预计需要花费 3 分钟才能阅读完成。
背景
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 利用内存一直上涨。
