3

公司内部一次关于OOM故障复盘分享 - 星巴克男孩

 2 years ago
source link: https://www.cnblogs.com/StarbucksBoy/p/15997901.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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

最近笔者有点忙，这次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<>();
缓存起来，下一次如果已经存在，就直接拿来用。
重新压测后效果还是明显的
总结
线上场景 特别对于一些新的框架或技术  如果你的流量很大，笔者那时参与了这个项目，工期特别短，功能又特别多，想着先上线，下一步再做压测，想不到等不到下一步问题就暴露出来了😄


 

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK