今早收到一条短信,具体报警信息如下:

【UMP JVM监控内存报警】应用名:发券worker(jdos_couponwkr);KEY【coupon.send.worker.jvm】,主机名:【host-10-183-72-114】,实例【11909223645】的堆内存使用率连续3次超过设定阀值【90.0%】。报警级别:【Warning】,报警时间:【2019-07-17 07:36:12】。

说是有一台机器的堆内存使用超过阈值90%。这条短信虽然言简意赅,但是背后隐藏的技术细节,我这里来陈述一下,谬误之处,还请指教。

初看此报警,则知道堆内存使用超过阈值了。第一反应一般都是把堆内内存调大,就行了。但是事实真的如此吗?不妨来一起看看。

假设我们现在堆内内存为1G,则堆内存使用曲线如下:

image

可以看到整体使用正常,回收正常,非常平稳。

现在,我们把堆内内存调整为2G,则堆内内存使用曲线如下:

image

可以看到,堆内内存使用率依然超过90%,说明单纯的调节堆内内存的大小,是无法解决此问题的。

为什么呢? 由于jvm工作的时候,对堆内内存的使用是自适应的,你给的多,它用的多,你给的少,它用的少。所以这也是为啥你给它1G大小,它能将堆内存用的超过90%,你给他2G大小,他也能将堆内存用的超过90%。当然,前提是应用的内存使用量大于2G才行。否则分配给2G的堆内存,则不会使用这么高。可能用到1.5G左右就释放了。

 

再来说说垃圾回收机制。这里我将G1算法之外的统称为老算法。咱们来比较一下:

在8G堆内存的docker上,同一个应用,同一业务,压测结果如下:

1. young gc次数,老算法20次,G1算法8次。

2. 堆内存使用最大值,老算法使用最大6.3G,G1算法使用最大7.6G。

可以看出,在8G堆内存的场景下,G1算法整体表现优异,更少的gc次数,更高效率的堆内存使用率。

但是在8G以下堆内存使用的场景中,G1算法则优势并不明显。所以强烈建议堆内存比较大的应用开启G1算法。

 

最后说下,遇到此短信提示需要检查的内容。

1. 检查yong gc耗时,平均耗时40ms以内正常,超过1s则需要排查问题。

2. 检查full gc次数,一分钟内数次或者数十次则显得频繁,需要排查。

3. 检查堆内存回收图形,如果内存使用率上去了,但是迟迟下不来,则意味着老年代无法回收,检查代码查明原因,类似图形如下:

image

可以看到此图中,曲线上去后下不来,原因是应用内部有个本地cache一直在运行且无过期机制导致,后来关闭掉此本地cache则回收正常。

4. 根据jvm使用率曲线的最高点来看当前堆内存大小是否符合设置,如果当前堆内存使用率顶点一直较高,则应用需要的内存比分配的堆内存要大一些,可以在内存资源足够的情况下尝试多分配一些堆内存。

posted on 2019-07-17 10:06  程序诗人  阅读(1606)  评论(0编辑  收藏  举报