H5W3
当前位置:H5W3 > java > 正文

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

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

bboyzqh发布于 今天 08:42

背景

12.08号中午营销mrc应用突然出现内存持续上涨,由开始的67%上升到85%左右(监控如下),好在上升过程比较慢,果断地重启解决了问题。解决问题和分析问题的过程如下。
【Java】2020年12月8号营销mrc应用内存突然上涨并导致系统OOM

解决问题过程

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

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应用内存不断上涨。

java
阅读 30更新于 今天 08:43
本作品系原创,采用《署名-非商业性使用-禁止演绎 4.0 国际》许可协议
avatar

bboyzqh
1 声望
0 粉丝

0 条评论
得票时间

avatar

bboyzqh
1 声望
0 粉丝

宣传栏

背景

12.08号中午营销mrc应用突然出现内存持续上涨,由开始的67%上升到85%左右(监控如下),好在上升过程比较慢,果断地重启解决了问题。解决问题和分析问题的过程如下。
【Java】2020年12月8号营销mrc应用内存突然上涨并导致系统OOM

解决问题过程

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

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应用内存不断上涨。

本文地址:H5W3 » 【Java】2020年12月8号营销mrc应用内存突然上涨并导致系统OOM

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址