关于java: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利用内存一直上涨。

【腾讯云】云产品限时秒杀,爆款1核2G云服务器,首年50元

阿里云限时活动-2核2G-5M带宽-60G SSD-1000G月流量 ,特惠价99元/年(原价1234.2元/年,可以直接买3年),速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据