写点什么

Inflation 引起的 MetaSpace Full GC 问题排查

  • 2020-07-20
  • 本文字数:4064 字

    阅读完需:约 13 分钟

Inflation 引起的 MetaSpace Full GC 问题排查

1 背景

本文将用一个蚂蚁集团线上实际案例,分享我们是如何排查由于 inflation 引起的 MetaSpace FGC 问题。


蚂蚁集团的智能监控平台深度利用了 Spark 的能力进行多维度数据聚合,Spark 由于其高效、易用、分布式的能力在大数据处理中十分受欢迎。


关于智能监控的计算能力相关介绍,可以参考《蚂蚁金服在 Service Mesh 监控落地经验总结》 。

2 案例背景

在某次线上问题中出现不间断性的任务彪高与积压,数据产出延迟,非常不符合预期。查看 SparkUI 的 Event Timeline 发现下边的现象:



大家应该都知道 Spark job 工作节点分为 driver 和 executor,driver 更多的是任务管理和分发,executor 负责任务的执行。在整个 Spark job 生命周期开始时这两种角色被新建出来,存活到 Spark job 生命周期结束。而上图中的情况一般为 executor 因为各种异常情况失去心跳而被主动替换。查看对应 executor 的日志发现有 2 分钟没有打印,怀疑为 FGC 卡死了。最终在另一个现场找到了 gc 日志:


2020-06-29T13:59:44.454+0800: 55336.665: [Full GC (Metadata GC Threshold) 2020-06-29T13:59:44.454+0800: 55336.665: [CMS[YG occupancy: 2295820 K (5242880 K)]2020-06-29T13:59:45.105+0800: 55337.316: [weak refs processing, 0.0004879 secs]2020-06-29T13:59:45.105+0800: 55337.316: [class unloading, 0.1113617 secs]2020-06-29T13:59:45.217+0800: 55337.428: [scrub symbol table, 0.0316596 secs]2020-06-29T13:59:45.248+0800: 55337.459: [scrub string table, 0.0018447 secs]: 5326206K->1129836K(8388608K), 85.6151442 secs] 7622026K->3425656K(13631488K), [Metaspace: 370361K->105307K(1314816K)], 85.8536592 secs] [Times: user=88.94 sys=0.07, real=85.85 secs]
复制代码


观察到因为 Metadata 的原因,导致 FGC,整个应用冻结 80 秒。众所周知 Metadata 主要存储一些类等相关的元信息,其应该是相对恒定的,那么究竟是什么原因导致了 MetaSpace 的变化,让我们一探究竟。

3 排查过程

MetaSpace 的目前参数为 -XX:MetaspaceSize=400m -XX:MaxMetaspaceSize=512m 这个已经非常多了,查看监控,发现 MetaSpace 的曲线如下图的锯齿状,这个说明不断的有类对象生成和卸载,在极端情况会到 400m 以上,所以触发 FGC 是符合常理的。但是整个应用的生命周期中,理论上不应该有大量的类在不断的生成和卸载。



先看下代码,是否有类动态生成,发现有 2 个地方比较可疑:


  1. QL 表达式,这个地方会有动态的类生成;

  2. 关键路径上泛型的使用;


但是经过排查和验证,发现这些都不是关键的点,因为虽然是泛型但类的数量是固定的,并且 QL 表达式有 cache。


最终定位到一个 Spark 算子,发现一个现象:每次执行 reduce 这个操作时都会有大量的类对象生成。


那么可以大胆的猜测:是由于 reduce 时发生 shuffle,由数据的序列化和反序列化引起。


添加启动参数,-XX:+TraceClassLoading -XX:+TraceClassUnloading ,在类加载和卸载的情况下可以看到明细信息,同时对问题现场做内存 dump,发现有大量的 DelegatingClassLoader,并动态的在内存中生成了 sun.reflect.GeneratedSerializationConstructorAccessor 类。



那么,很明显引起 MetaSpace 抖动的原因就是 DelegatingClassLoader 生成了很多 ConstructorAccessor 对应的类对象,这个类是动态生成的,保存在内存中,无法找到原型。


为了查看内存中这个类的具体信息,找到原型,这里用到了一个非常强大的工具:arthas,arthas 是 Alibaba 开源的 Java 诊断工具,推荐每一位研发人员学习,具体教程见 :


https://alibaba.github.io/arthas/quick-start.html


arthas 可以很方便的观察运行中的 JVM 的各种状态,找一个现场用 classloader 命令观察,发现有好几千 DelegatingClassLoader:



随便挑一个 DelegatingClassLoader 下的类反序列化看下,整个类没什么特别的,就是 new 一个对象出来,但是有个细节:引入了 com.alipay 这个包下的类,这个地方应该能提供什么有用的信息。



我们尝试把所有 GeneratedSerializationConstructorAccessor 的类 dump 下来做下统计,OpenJDK 可以做 ClassDump,找了下社区发现个小工具:


https://github.com/hengyunabc/dumpclass


java -jar dumpclass.jar -p 1234 -o /home/hadoop/dump/classDump sun.reflect.GeneratedSerializationConstruc*
复制代码


可以看到导出了大概 9000 个 GeneratedSerializationConstructorAccessor 相关的类:



用 javap 反编译后做下统计:


find ./ -name "GeneratedSerializationConstructorAccessor*" | xargs javap -verbose | grep "com.alipay.*" -o |  sort | uniq -c
复制代码



发现有的类只生成 3 次,有的上千次,那么他们区别是什么?对比下发现差别在是否有默认的构造函数。

4 根因分析

根因是由于在反序列化时触发了 JVM 的“inflation”操作,关于这个术语,下边这个解释非常通俗易懂:


“When using Java reflection, the JVM has two methods of accessing the information on the class being reflected. It can use a JNI accessor, or a Java bytecode accessor. If it uses a Java bytecode accessor, then it needs to have its own Java class and classloader (sun/reflect/GeneratedMethodAccessor class and sun/reflect/DelegatingClassLoader). Theses classes and classloaders use native memory. The accessor bytecode can also get JIT compiled, which will increase the native memory use even more. If Java reflection is used frequently, this can add up to a significant amount of native memory use. The JVM will use the JNI accessor first, then after some number of accesses on the same class, will change to use the Java bytecode accessor.This is called inflation, when the JVM changes from the JNI accessor to the bytecode accessor. Fortunately, we can control this with a Java property. The sun.reflect.inflationThreshold property tells the JVM what number of times to use the JNI accessor. If it is set to 0, then the JNI accessors are always used. Since the bytecode accessors use more native memory than the JNI ones, if we are seeing a lot of Java reflection, we will want to use the JNI accessors. To do this, we just need to set the inflationThreshold property to zero.”


由于 spark 使用了 kryo 序列化,翻译了相关代码和文档:


InstantiatorStrategy

Kryo provides DefaultInstantiatorStrategy which creates objects using ReflectASM to call a zero argument constructor. If that is not possible, it uses reflection to call a zero argument constructor. If that also fails, then it either throws an exception or tries a fallback InstantiatorStrategy. Reflection uses setAccessible, so a private zero argument constructor can be a good way to allow Kryo to create instances of a class without affecting the public API.

DefaultInstantiatorStrategy is the recommended way of creating objects with Kryo. It runs constructors just like would be done with Java code. Alternative, extralinguistic mechanisms can also be used to create objects. The Objenesis StdInstantiatorStrategy uses JVM specific APIs to create an instance of a class without calling any constructor at all. Using this is dangerous because most classes expect their constructors to be called. Creating the object by bypassing its constructors may leave the object in an uninitialized or invalid state. Classes must be designed to be created in this way.

Kryo can be configured to try DefaultInstantiatorStrategy first, then fallback to StdInstantiatorStrategy if necessary.

kryo.setInstantiatorStrategy(new DefaultInstantiatorStrategy(new StdInstantiatorStrategy()));

Another option is SerializingInstantiatorStrategy, which uses Java’s built-in serialization mechanism to create an instance. Using this, the class must implement java.io.Serializable and the first zero argument constructor in a super class is invoked. This also bypasses constructors and so is dangerous for the same reasons as StdInstantiatorStrategy.

kryo.setInstantiatorStrategy(new DefaultInstantiatorStrategy(new SerializingInstantiatorStrategy()));


结论很清晰:


如果 Java 对象有默认的构造函数,DefaultInstantiatorStrategy 调用 Class.getConstructor().newInstance() 构建出来。在这个过程中 JDK 会将构造出来的 constructor accessor 缓存起来,避免反复生成。


否则 StdInstantiatorStrategy 调用 Java 的特殊 API(如下图的 newConstructorForSerialization)直接生成对象而不通过构造函数。


相关的代码在:


org.objenesis.instantiator.sun.SunReflectionFactoryHelper#getNewConstructorForSerializationMethod



这个过程中没有 cache 的过程,导致不断的生成 constructor accessor,最后发生 inflation 生成了非常多的 Metadata。

5 总结

inflation 是一个比较冷门的知识,但是每一个研发应该都会在有意无意见遇到它。那么在使用反射的能力时、甚至是第三方库在大量使用反射来实现某些功能时,都需要我们去注意和思考。


同时,问题的排查是需要按逻辑去思考和渐进寻找根因的,脑袋一团乱麻只会走不少弯路,引以为戒。最后本文问题通过添加私有构造函数后解决,MetaSpace 监控空锯齿状消失:



作者介绍


凌屿,高级开发工程师,一直从事智能监控相关研发工作,在海量数据清洗、大数据集处理、分布式系统建设等有深入研究。


本文转载自公众号蚂蚁智能运维(ID:gh_a6b742597569)。


原文链接


https://mp.weixin.qq.com/s/uwLXDfFmW1aFVeKNY9N79Q


2020-07-20 10:002435

评论 1 条评论

发布
用户头像
写的非常好,最近遇到了inflation的问题,感谢分享!
2023-03-01 19:56 · 广东
回复
没有更多了
发现更多内容

如何化解35岁危机?华为云数据库首席架构师20年技术经验分享

华为云开发者联盟

中年危机 经验分享 华为云

openGauss内核:简单查询的执行

华为云开发者联盟

数据库 互联网 华为云

海泰前沿技术|隐私计算技术在医疗数据保护中的应用

电子信息发烧客

如何抓手机的包进行分析,Fiddler神器或许能帮到您!

wljslmz

抓包 fiddler 6月月更

共享洗车机多少钱一台?看品牌

共享电单车厂家

自助洗车机价格 自助洗车加盟 共享洗车机多少钱

Redis+Caffeine两级缓存,让访问速度纵享丝滑

码农参上

redis 缓存 JAVA开发 Caffeine

《各行业零代码企业应用案例集锦》正式发布

明道云

Datakit 代理实现局域网数据统一汇聚

观测云

架构实战营 第 6 期 毕业设计

火钳刘明

#架构实战营 「架构实战营」

架构实战营 第 6 期 毕业总结

火钳刘明

主数据建设的背景

奔向架构师

数据仓库 主数据 6月月更

Guava中这些Map的骚操作,让我的代码量减少了50%

码农参上

JAVA开发 Guava java工具包

建木持续集成平台v2.5.0发布

Jianmu

开源 DevOps CI/CD Worker 建木CI

应用实践 | 海量数据,秒级分析!Flink+Doris 构建实时数仓方案

SelectDB

数据库 flink 数据分析 Doris 数仓

为什么生命科学企业都在陆续上云?

阿里云弹性计算

HPC 高性能计算 生命科学 基因测序

心楼:华为运动健康的七年筑造之旅

脑极体

牛客java选择题每日打卡Day1

京与旧铺

6月月更

Volcano成Spark默认batch调度器

华为云开发者联盟

云计算 数据分析 后端

XTransfer技术新人进阶秘诀:不可错过的宝藏Mentor

XTransfer技术

职场新人 职场经验

升哲科技 AI 智能防溺水服务上线

SENSORO

大数据 AI 物联网

畅直播|针对直播痛点的关键技术解析

ZEGO即构

直播体验升级 首帧秒开

面试官:你说你精通Redis,你看过持久化的配置吗?

阿Q说代码

redis aof rdb 数据持久化

我国SaaS产业的发展趋势与路径

小炮

优酷 Android 包瘦身治理思路全解

阿里巴巴文娱技术

治理 包大小

如何做到全彩户外LED显示屏节能环保

Dylan

LED显示屏 全彩LED显示屏 户外LED显示屏

即构「畅直播」上线!提供全链路升级的一站式直播服务

ZEGO即构

一文理解OpenStack网络

华为云开发者联盟

后端 网络

TDengine可通过数据同步工具 DataX读写

TDengine

数据库 tdengine 时序数据库 DataX

AntDB数据库在线培训开课啦!更灵活、更专业、更丰富

亚信AntDB数据库

数据库 AntDB 培训学习 数据库·

在shiro基础上整合jwt,可在项目中直接使用呦

阿Q说代码

springboot Java EE 权限验证 shiro整合jwt

车白兔:洗车新模式共享自助洗车

共享电单车厂家

自助洗车 自助洗车加盟 车白兔洗车

Inflation 引起的 MetaSpace Full GC 问题排查_大数据_凌屿_InfoQ精选文章