性能文章>公司内部一次关于OOM故障复盘分享>

公司内部一次关于OOM故障复盘分享转载

2月前
320216

最近笔者有点忙,这次OOM事故发生过去两周前,记得笔者那天正带着家人在外地玩,正中午跟友人吃饭的时候,钉钉连续告警爆表,接着就是钉钉电话(显示广东抬头)一看就知道BBQ了,又一次故障发生了,今天把那次故障复盘一下,做个总结,也给小伙伴分享一下 我是怎么从接到告警开始,怎么一步一步分析故障,然后定位到问题,最后完美解决,成功上线解决问题的。

 

 

上述告警内容,由于笔者所在服务是用CMS垃圾回收器,当其GC次数太频繁,达到公司监控平台设置的阈值时,就会通过钉钉通知告知开发者,发送到对应的控制台上。这个异常先从字面意义上来说倒也比较明显,如果老年代里的对象太多,无法提供空间容纳年轻代传递过来的对象的时候,就会触发FULL GC。

这里我们先简单分析一下,对象什么情况下会进入老年代,以及老年代又是在什么情况下会触发FULL GC?只有先知道了原理性东西,你才能带着思路去分析,真实线上场景属于对应哪种情况

首先科普一下对象什么情况下会进入老年代?

1)躲过15次GC之后进入老年代

public class Kafka{
//只要Kafka这个类存在,r这个静态变量就会一直存在
private static ReplicManager r=new ReplicManager();
}
像上面这块代码,成员变量是GCROOT引用,所以一直不会回收不掉;这个对象每次从Eden躲过一次到Survivor区域中,它的年龄就增长1岁,当年龄增加到15岁时候,就会转移到老年代里。
 
2)动态对象年龄判断
意思是如果Survivor空间中相同年龄的所有对象大小总和大于Survivor空间的一半,年龄大于等于该年龄的对象会直接进入老年代
 
3)大对象直接进入老年代
 
4)空间担保策略
在发生MinorGc之前,JVM会检查老年代的最大连续可用空间是否大于新生代所有对象总空间,如果不成立,那么JVM会查看一个参数值查看是否允许担保,如果之前配置了允许,那么会检查老年代最大可用空间是否大于历次晋升到老年代对象的平均大小,如果大于将尝试进行一次Minor GC;如果小于或者参数设置不允许冒险,那么就会进行一次FULL GC。
 
那老年代又是在什么情况下会触发FULL GC?
1.也是上面第四种情况,就不写了
2.yongGC之后如果满足上述分析的[#首先科普一下对象什么情况下会进入老年代?]其中一种情况,那么进入老年代,但这个时候如果老年代空间不足,就会触发FULLGC
3.如果老年代内存使用率超过92%其实会触发fullgc的
 
好了先科普一下相关知识点,利于后续的分析做铺垫。下面开始逐步分析具体具体原因,到底是什么大对象充满了老年代内存区域。
 
首先一碰到特别是线上这种重大事故,第一思路是保留线程,然后快速止血。这也是笔者所在公司对于开发的其中一条军规(估计之前出现过太多的这种事故,形成规范了😄)。
那我也按照这种思想,通过日志分析,马上知道这个是有同时在批量导数据,导致入口流量很大,先联系同时快速止血,暂停导入操作。果然没多久 就不报警了,告警恢复通知一个接一个过来。
 
接下来我们开始分析到底是什么对象快速把老年代给填满了,相应入口在哪里。
先看业务监控大图:

 

 

现象是从下午4点开始内存有一波快速增长。
通过阿里的Arthas分析工具,通过命令dashboard查看当下系统的实时信息。
(下面这张图已经是止血之后文档的图了,但老年代还是填充了不少对象的)

 

 

线上由于比较麻烦dump线程。而且现场已经过去了,所以我还是自己写了一段压测代码(类似Jmeter效果),来压测相应的总入口,看看具体是哪个对象占了大内存

 

 

 很明显是有一个nashorn相关对象占据了比较大的占比。那这个对象其实对应笔者的程序是

ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
Compilable compEngine = (Compilable) engine;
try {
CompiledScript compile = compEngine.compile(script);
}catch(Exception e){

}

简单来说,Nashorn的编译入口可以从 Context.compileScript() 开始看:[ JavaScript源码 ] -> ( 语法分析器 Parser ) -> [ 抽象语法树(AST) ir ] -> ( 编译优化 Compiler ) -> [ 优化后的AST + Java Class文件(包含Java字节码) ] -> JVM加载和执行生成的字节码 -> [ 运行结果 ]

此过程是十分耗时的,每次执行eval 去运行js ,都需要编译成字节码、然后加载执行。同时会将编译过的字节码缓存起来,以便后续使用,因此加载的类会长时间存活,占用很大的内存空间。

所以笔者尝试将CompiledScript这一对象第一次编译完后,本地缓存起来用

private static Map<Long, CompiledScript> scriptMap = new ConcurrentHashMap<>();
缓存起来,下一次如果已经存在,就直接拿来用。
重新压测后效果还是明显的

 

总结
线上场景 特别对于一些新的框架或技术 如果你的流量很大,笔者那时参与了这个项目,工期特别短,功能又特别多,想着先上线,下一步再做压测,想不到等不到下一步问题就暴露出来了😄


作者:星巴克男孩
来源:博客园
 
 

 

文章来源:博客园

原文链接:https://www.cnblogs.com/StarbucksBoy/p/15997901.html

请先登录,再评论

大佬

2月前

为你推荐

OutOfMemoryError之unable to create new native thread原因分析及6种解决方案
java.lang.OutOfMemoryError:unable to create new native thread 是比较常见的一种异常,表示应用程序无法创建新的线程。产生该异常,总体上可总结
java内存溢出问题分析过程
背景运维人员反馈一个容器化的java程序每跑一段时间就会出现OOM问题,重启后,间隔大概两天后复现。 问题调查 一、查日志由于是容器化部署的程序,登上主机后使用docker logs Containe
为什么容器内存占用居高不下,频频 OOM(续)
在之前的文章《[为什么容器内存占用居高不下,频频 OOM](https://heapdump.cn/article/1589003)》 中,我根据现状进行了分析和说明,收到了很多读者的建议和疑
Java OOM 实战篇:应用故障之Java heap space 堆溢出实战
以下是用于测试OOM的测试代码:```javapublic class HeapMemUseTest { public static void main(String[] args) {
一则OOM死机故障的处理过程
OOM是Out of Memory的简写,也就是内存不足。出现该问题的原因有很多,如程序内存泄漏等。内存泄漏问题可以通过定时地终止和重启有问题的程序来发现和解决。在比较新的Linux内核版本中,有一种
导致程序出现OOM的因素,夜深人静的时候,程序OOM异常追踪
作为Java程序员, 除了享受垃圾回收机制带来的便利外, 还深受OOM(Out Of Memory)的困惑和折磨。 堆溢出(heap)编写如下例程:```javapublic static void
导致程序出现OOM的因素,夜深人静的时候,程序OOM异常追踪
作为Java程序员, 除了享受垃圾回收机制带来的便利外, 还深受OOM(Out Of Memory)的困惑和折磨.先来看下java的内存分布 堆溢出(heap)编写如下例程:```javapublic
首次排查 OOM 实录
前言距离上篇文章更新已经一月有余,之所以一直没更新一是工作最近比较忙,二是感觉产出不了什么对自己和他人有价值的文章。因此这段时间,主要的空闲时间在学习技术和写 GitHub,博客这边就暂时落下了。本篇