一次线上OOM事故,学会一个小众JVM参数

前言

作为一个刚入职一坤(2.5)月的校招生,本想着能好好的水一段时间,万万没想到带我的menter让我去复盘一个线上OOM事故,并给出一个解决方案。我当时心情

首先,这个OOM事故发生后menter就做了紧急的措施:重启机器、回滚代码,让这个事故没有产生更大的影响。

事故现象

简单描述一下这个事故现象,首先我们收到了多个服务的接口调用异常告警,当我们正在排查这些服务为什么突然告警的过程中,又收到了服务A(内部项目不便透露)发生了OOM。然后我们就意识到了为什么那些服务发生了告警,因为这些告警服务都依赖喻服务A,服务A发生了OOM使得依赖它的服务都发生了告警。在服务A发生OOM后,它的2台机器直接宕机了。我们立马采取了补救措施:重启机器,回滚代码。 事后查看各种各种监控平台发现,是因为发生了Full GC但未成功回收到预期的空间发生了OOM。

事故背景

在一个平常的发布中,项目代码发布完成后,需要通过Apollo打开一个开关。这个开关打开后,会将原本单引擎的规则计算变为双引擎计算,新增的计算引擎为Aviator。

此处的规则计算概念就是现今市场流行的规则引擎(如:drools)计算概念

排查过程

具体的排查过程,由表象OOM问题逐步深入到JVM元空间的垃圾回收、Aviator引擎底层源码。

为什么发生Full GC

首先,从表象看是发生了OOM。发生OOM前肯定会发生Full GC,机器才刚启动为什么会立马将堆内存打满呢?查看监控发现,确实发生了Full GC,但发生Full GC时堆空间内存使用占比不足5%。这个时候就更懵逼了。那是什么原因触发了Full GC呢?再更细致的查看监控后,发现发生Full GC时metaSpace空间使用占比同时也飙升。

此时,不由的怀疑触发Full GC是否是因为metaSpace空间使用占比飙升引起的呢?但通过监控可以看到发生Full GC时metaSpace使用占比仅仅在75%左右,并没有达到设置的MaxMetaspaceSize=256m。在翻阅了《深入理解Java虚拟机》以及众多技术博客想去了解metaSpace扩容原理后还是没有找到对应的答案。这个时候不得不说大数据的神奇了,当我在各大技术论坛、网站搜索这类信息后,给我推了这篇文章,让我了解到了MaxMetaspaceFreeRatio参数,这个参数意思是当metaSpace空间占比达到该阈值后就进行Full GC,默认为70%。这就可以闭环为什么会在75%左右发生Full GC了。

metaSpace空间使用占比为什么会飙升

在解决为什么会发生Full GC问题后,此时就引入了另外一个问题,metaSpace空间使用占比为什么会飙升。懵逼的我是想到懵逼,这该怎么查啊。回想当初学习JVM的时候对metaSpace的了解只停留在metaSpace中存储着类的元数据、字符串常量等信息。到这里心想只能去分析dump文件了。经过多次踩坑分析后,发现一个奇特的现象,metaSpace中存在大量以"Script_"开头的类的元数据和大量的AviatorClassLoader类加载器。

看到AviatorClassLoader类加载器这个名字,这不呼应上了嘛。我们当时的操作就是开启了Aviator引擎。 而后,为了验证这一猜测,我在测试环境进行了事故复现。发现确实是因为"Script_"开头的类的元数据和大量的AviatorClassLoader类加载器大致的metaSpace空间使用占比飙升。

为什么会产生大量"Script_"开头的类和AviatorClassLoader类加载器

后续,我对项目中调用的Aviator代码以及引入的Aviator源码进行了分析。发现 项目中调用Aviator的这个方法

css 复制代码
AviatorEvaluator.compile(a + "+" + b);

在Aviator引擎中实际存在着多个重载实现,其中包含了缓存方法。

typescript 复制代码
public static Expression compile(String expression, boolean cached) {
    return getInstance().compile(expression, cached);
}

public static Expression compile(String expression) {
    return compile(expression, false);
}

我们在项目中使用的是不使用缓存的方法。深入分析该方法后发现若不使用缓存方法,Aviator每次调用都将new一个AviatorClassLoader类加载器,并且为每个计算表达式生成一个以"Script_"开头的类。

kotlin 复制代码
private Expression innerCompile(final String expression, final String sourceFile,
    final boolean cached) {
  ExpressionLexer lexer = new ExpressionLexer(this, expression);
  CodeGenerator codeGenerator = newCodeGenerator(sourceFile, cached);
  ExpressionParser parser = new ExpressionParser(this, lexer, codeGenerator);
  Expression exp = parser.parse();
  if (getOptionValue(Options.TRACE_EVAL).bool) {
    ((BaseExpression) exp).setExpression(expression);
  }
  return exp;
}

public AviatorClassLoader getAviatorClassLoader(final boolean cached) {
  if (cached) {
    return this.aviatorClassLoader;
  } else {
    return new AviatorClassLoader(this.getClass().getClassLoader());
  }
}

public ASMCodeGenerator(final AviatorEvaluatorInstance instance, final String sourceFile,
    final AviatorClassLoader classLoader, final OutputStream traceOut) {
  super(instance, sourceFile, classLoader);
  this.className = "Script_" + System.currentTimeMillis() + "_" + CLASS_COUNTER.getAndIncrement();
  this.classWriter = new ClassWriter(ClassWriter.COMPUTE_FRAMES);
  visitClass();
}

public Expression getResult(final boolean unboxObject) {
  end(unboxObject);

  byte[] bytes = this.classWriter.toByteArray();
  try {
    Class<?> defineClass =
        ClassDefiner.defineClass(this.className, Expression.class, bytes, this.classLoader);
    Constructor<?> constructor =
        defineClass.getConstructor(AviatorEvaluatorInstance.class, List.class, SymbolTable.class);
    BaseExpression exp = (BaseExpression) constructor.newInstance(this.instance,
        new ArrayList<VariableMeta>(this.variables.values()), this.symbolTable);
    exp.setLambdaBootstraps(this.lambdaBootstraps);
    exp.setFuncsArgs(this.funcsArgs);
    exp.setSourceFile(this.sourceFile);
    return exp;
  } catch (ExpressionRuntimeException e) {
    throw e;
  } catch (Throwable e) {
    if (e.getCause() instanceof ExpressionRuntimeException) {
      throw (ExpressionRuntimeException) e.getCause();
    }
    throw new CompileExpressionErrorException("define class error", e);
  }
}

这样看来,这次OOM事故的这个原因分析的就差不多了。是由于调用Aviator引擎时compile()方法并没有使用缓存,使得每次计算时都会创建一个AviatorClassLoader类加载器以及以"Script_"命名开头的类。当大量流量进入后,使得metaSpace使用占比飙升,进而产生了OOM。

解决思路

在排查完问题原因后,提出了如下解决方案:

  • 使用Aviator缓存方法: 将原本的compile("1+1")方法替换为compile("1+1",true)缓存方法,避免相同的计算表达式重复计算,导致大量用途相同的AviatorClassLoader和"Script_"类重复产生。
  • 修改JVM参数,提高metaSpace最大内存 将原本MaxMetaspaceSize=256m修改为MaxMetaspaceSize=512m,因为在未发生OOM时metaSpace空间占比已经达到了65%距离触发Full GC的70%的波动空间较小。

那么为什么不修改MaxMetaspaceFreeRatio这个参数呢? 公司中间件不支持修改这个参数

  • 上线前压测 这个事故的产生,同时也暴露出了我们组对部分高QPS的接口并没有进行充分了压测。在后续开发过程中,需要对高QPS接口进行充分的压测,让这类问题扼杀在摇篮之中。

收获

通过这次事故原因复盘经历,我收获了很多实际问题解决的经验。

  • 对此类问题有了基本的排查方向和思路
  • 认识到了一个很小众的JVM参数:MaxMetaspaceFreeRatio。这个参数被提及的很少,就连大名鼎鼎的《深入理解Java虚拟机》都没有提及。
  • 认识到压测的重要性
相关推荐
2401_857610031 小时前
SpringBoot社团管理:安全与维护
spring boot·后端·安全
Ysjt | 深2 小时前
C++多线程编程入门教程(优质版)
java·开发语言·jvm·c++
凌冰_2 小时前
IDEA2023 SpringBoot整合MyBatis(三)
spring boot·后端·mybatis
码农飞飞2 小时前
深入理解Rust的模式匹配
开发语言·后端·rust·模式匹配·解构·结构体和枚举
一个小坑货2 小时前
Rust 的简介
开发语言·后端·rust
monkey_meng2 小时前
【遵守孤儿规则的External trait pattern】
开发语言·后端·rust
Estar.Lee2 小时前
时间操作[计算时间差]免费API接口教程
android·网络·后端·网络协议·tcp/ip
新知图书3 小时前
Rust编程与项目实战-模块std::thread(之一)
开发语言·后端·rust
盛夏绽放4 小时前
Node.js 和 Socket.IO 实现实时通信
前端·后端·websocket·node.js
Ares-Wang4 小时前
Asp.net Core Hosted Service(托管服务) Timer (定时任务)
后端·asp.net