Java应用OOM问题排查:8G内存,4G堆,为何还会OOM?

Java应用8G内存,4G堆却OOM?元凶竟是多个ClassLoader加载的netty内存分配器,导致堆外内存超出限制。

原文标题:8G的容器Java堆才4G怎么就OOM了?

原文作者:阿里云开发者

冷月清谈:

本文记录了一次Java应用OOM问题的排查过程,该应用容器内存为8G,Java堆设置为4G,堆外内存设置为1G。通过监控发现,实际堆外内存占用超过了1G限制,最终导致OOM。

排查过程中,首先通过Native Memory Tracking (NMT) 观察到堆外内存(Other部分)占用异常,最高达到接近1.5GB。尝试调整jemalloc内存分配器参数后,内存占用略有下降,但仍超过1G,因此排除jemalloc问题。

接着使用perf工具监控内存分配调用栈,但未发现明显线索。随后dump可疑内存块并分析,发现大量内容与RocketMQ相关,但未发现异常。

在JVM专家的建议下,将堆外内存调小至512M进行测试,结果导致MQ消息消费不及时。由此推断,MQ客户端占用了超过512M的堆外内存。

通过分析netty内存管理核心类`io.netty.buffer.PooledByteBufAllocator`,发现netty直接使用UNSAFE.allocateMemory分配内存,绕过Java直接内存API,并自行实现内存占用限制。该限制值通常等于JVM参数MaxDirectMemorySize。

使用Arthas工具查看 `io.netty.buffer.PooledByteBufAllocator#DEFAULT` 静态变量,发现该应用中存在7个不同的Allocator实例,分别由不同的ClassLoader加载,累计占用超过1G,与NMT观测到的Other类别内存大小吻合。

最终结论是,多个ClassLoader加载了多个netty的`io.netty.buffer.PooledByteBufAllocator`,每个Allocator都有1G的内存配额,导致实际堆外内存超出1G限制。短期解决方案是调小Java堆,长期方案需要与中间件团队沟通优化。

怜星夜思:

1、文中提到netty使用UNSAFE.allocateMemory分配内存绕过JVM管理,这样做除了性能优势外,还有什么其他好处?这种方式是否存在风险?
2、文中提到了RocketMQ客户端占用了大量的堆外内存,RocketMQ客户端在哪些场景下会大量使用堆外内存?有什么方法可以优化RocketMQ客户端的内存使用?
3、多个ClassLoader加载同一个类导致资源浪费的问题,除了文中提到的netty,还有哪些常见的场景?有什么通用的解决方案?

原文内容

阿里妹导读


本文记录最近一例Java应用OOM问题的排查过程,希望可以给遇到类似问题的同学提供参考。

前言:此文记录最近一例Java应用OOM问题的排查过程,希望可以给遇到类似问题的同学提供参考。在本地集团,大多数情况下Java堆的大小会设置为容器规格的50%~70%,但如果你设置为50%时还是遇到了OS OOM的问题,会不会无法忍受进而想要知道这是为什么?没错,我也有一样的好奇。

背景

某核心应用的负责同学反馈应用存在少量机器OOM被OS kill的问题。看sunfire监控信息,的确如此。









初步收集到的信息:

容器内存=8G,Java 11,G1 GC=4G,MaxDirectMemorySize=1G。详见下图:





业务同学已经做过Java dump,可以看到堆外对象几乎没有,堆内的使用量也不大,<3G。上机器查看Java进程的内存使用量的确很大:





通过目前掌握到的信息来看,4G(Java堆)+1G(堆外)+512M(元空间)+250M(CodeCache)+其它,离6.8G还是有不少差距,无法简单的明确原因,需要深入排查分析了。

问题结论


省流版

中间件中多个不同的ClassLoader加载了多个netty的io.netty.buffer.PooledByteBufAllocator,每一个都有1G的内存配额,所以存在实际使用的堆外内存超出1G限制的问题。

通过Arthas可以看到存在这个类的7个不同的实例:





而其中rocketmq-client的这一个,已经基本用完1G的内存(其它几个使用量大多在100多M的样子):





详细版

中间件中多个不同的ClassLoader加载了多个netty的io.netty.buffer.PooledByteBufAllocator,每个Allocator都用自己的计数器在限制堆外内存的使用量,这个限制值大多数情况下取值至MaxDirectMemorySize,所以会存在无法限制堆外内存使用量在1G以内的问题。(这个设计是否合理,还请中间件的同学帮忙补充了)

这个应用是饿了么弹内的应用,io.netty.buffer.PooledByteBufAllocator,有7个ClassLoader加载了它,分别是:

sentinel's ModuleClassLoader、rocketmq-client's ModuleClassLoader、tair-plugin's ModuleClassLoader、hsf's ModuleClassLoader、XbootModuleClassLoader、pandora-qos-service's ModuleClassLoader、ele-enhancer's ModuleClassLoader

相比弹内应用的4个(数据来自淘天集团的核心应用ump2,如下图),多了3个。





在Java8,以及Java11中(JVM参数设置了-Dio.netty.tryReflectionSetAccessible=true过后),netty会直接使用unsafe的方法申请堆外内存,不通过Java的DirectMemory分配API,所以通过监控看不到堆外内存的占用量,也不受JVM MaxDirectMemorySize的管控。

查看DirectByteBuffer实现代码可以发现,它限制MaxDirectMemorySize的方法是在Java层(代码标记处1),实际上在JVM底层是没有任何限制的,netty是直接用了这里代码标记处2的API分配内存。





排查过程

1.1.通过NativeMemoryTracking看Native内存的占用分布

通过在JVM参数上加上-XX:NativeMemoryTracking=detail,就可以打印出详细的内存分类的占用信息了,观察了一整天,发现主要的可疑变化是在Other部分,即堆外的部分,如下图。( Java NMT的详细使用可以参考相应的技术文章)





明明是限制的堆外1G,怎么超过了这么多。再多观察一会,发现它还会继续缓慢上涨的,最高达到接近1.5GB。这就和最开始查看Java进程的RSS占用对上了。

1.2.native内存泄漏了吗

JVM使用什么native分配器

通过查看机器上安装的JDK的信息,可以看到使用的是jemalloc的内存分配器。是不是它有泄漏、内存碎片、归还不及时的问题?

网上搜索,发现的有一篇文章讲的场景和我们这里的有一些类似。(https://blog.csdn.net/liulilittle/article/details/137535634)

尝试重新下载jemalloc的源码,并进行其参数的调整:

export MALLOC_CONF="dirty_decay_ms:0,muzzy_decay_ms:0"

观察发现内存的占用量有少量的下降,但还是会超过1个G,看起来核心问题不在这里。

谁在分配内存

同时还通过perf工具监控了下调用内存分配的调用栈,想看看有什么线索没有,然而并没有什么线索。毕竟这个内存的增长比较缓慢,perf也不可能抓太长时间了,遂放弃这个思路。

sudo perf probe -x /opt/taobao/install/ajdk11_11.0.23.24/lib/libjemalloc.so.2  malloc

sudo perf record -e probe_libjemalloc:malloc -p `pidof java` -g -- sleep 10





内存里面装了什么

通过 sudo pmap -x `pidof java` | sort -k 3 -n 命令查看进程的所有内存块信息,如下图示:





排除最大的4G的这一个(这是Java堆),以及内存标志带x的两个(可执行代码标志,那是CodeCache),把其它的块都dump下来,看看里面都放了啥,有没有什么不平凡的。

使用gdb命令:gdb --batch --pid `pidof java` -ex "dump memory mem1.log 0x7f0109800000 0x7f0109800000+0x200000"

然后将dump下的内存以字符串的方式输出观察下:cat mem1.log | strings









如图所示,发现里面大量的内容都和RocketMQ有关。不过我发现我早率了,这些dump内容我看了快一天,根本没有发现什么不太对的地方,看起来都是正常的占用。(不过明显能看出来这里面存了一堆消费者信息,表达的比较冗余)

求助JVM专家

还真是从入门到放弃,到这个时候已经没啥信心啦。遂求助于JVM的专家毛亮,他给了大的方向,一是这里不太可能有native的内存泄漏,二是既然怀疑是堆外,把堆外内存减少一点看看情况,明确下是不是native内存分配器的回收特性就是这样。往往native的内存分配器都有自己的管理策略,他会有自己的回收拐点,比应用看到的高一点是合理的。

的确,那么接下来的策略就是把MaxDirectMemeorySize调低到512M观察下效果吧。

1.3.堆外内存调小影响业务了

在堆外内存从1G调小到512M过后,过了个周末,周一的时候业务同学就反馈,调小遇到问题了,存在MQ消息消费不及时而导致消息挤压的问题。结合之前看到的native内存的信息,突然想到,MQ客户端一定是占用了超过512M的内存,内心里出现了两个问题:

1.MQ底层依赖netty,那么netty实际使用的内存是多少?以及这个内存占用量和native的堆外占用量是什么关系?

2.为啥Java的DirectMemory占用这么少,netty的内存占用似乎并没有被看到,这是怎么回事?

带着这两个问题,查看了netty内存管理的核心类 io.netty.buffer.PooledByteBufAllocator,以及机器上启动过程中打印出的信息。





结合这里面涉及的另一个核心类io.netty.util.internal.PlatformDependent,大概明白了这里面的逻辑,netty是直接使用(是有前提条件的,但这个应用通过JVM参数[-Dio.netty.tryReflectionSetAccessible=true]开启了这个特性,这也是大多数应用上面的行为)UNSAFE.allocateMemory分配内存,完全绕过Java的直接内存API。然后它自己实现了内存占用空间的限制,这个值等于JVM参数中的MaxDirectMemorySize。到这里,似乎发现了曙光,莫非就是netty?(netty这么做的原因是为了不依赖JVM机制而加速内存的释放,同时也是为了解决在堆外内存不足时JVM的糟糕的回收机制设计。)

1.4.Netty到底占用了多少内存

好在netty的类中有一个静态变量是可以很容易的看到这个信息的:

io.netty.buffer.PooledByteBufAllocator#DEFAULT。

那么这个时候就是需要上机器去执行它了。Arthas是个不错的工具,可以直接在机器执行表达式看任何静态变量的值,并不需要我们改代码然后去调用上面的对象做日志打印。

登录机器后,通过命令查找netty Allocator的类定义:

sc -d io.netty.buffer.PooledByteBufAllocator





发现有不止一个Allocator,来自于不同的ClassLoader,以及不同的jar包。一共有7个。

然后一个一个的看他们实际占用的大小:

getstatic -c d5bc00 io.netty.buffer.PooledByteBufAllocator DEFAULT





然后把他们占用的内存逐项加起来,发现的确超过了1G,同时和前面通过NMT看到的Other类别的内存大小是比较吻合的。到这里大概就明确具体是怎么回事了,内存是netty用掉的。

1.5.业务应该怎么做呢

到目前为此,问题是明确了,但似乎并没有什么太好的解法。一个是rocketmq-client的内存占用是不是太大了,有没有什么可以优化的地方?(从前面看native内存看到的内容来看,还是有很大的优化空间的,一大堆地址信息都是以字符串的形式写在内存里面),另一个是中间件的调整肯定是长期的,短期业务要怎么办呢?

思考再三,短期来看只能是先让业务把Java堆调小(通过Java dump以及JVM监控可以看出来堆的使用率并不高),来适应当前的现状了。

至于堆外内存大小没有限制住的问题,我感觉并不是中间件同学的预期之中的,这块后面也找相关同学聊一聊。

后记

以后排查Java堆外内存过大的问题,优先看netty的占用。


代码智能生成,AI编码助手搭建攻略


随着人工智能技术的飞速发展,开发人员面临着代码编写效率和质量的双重挑战。为了提高编程效率、减少错误并加速创新,市场对智能编码助手的需求日益增长。本方案旨在介绍如何部署AI模型,构建一个基于私网的AI编码助手,以辅助开发者高效完成编程任务。   


点击阅读原文查看详情。



绕过JVM直接内存管理,可以避免JVM在堆外内存不足时的糟糕回收机制,提升内存分配和释放效率。但是,这种方式也存在风险,例如内存泄漏难以排查,需要依赖netty自身的内存管理机制。

“文中提到netty使用UNSAFE.allocateMemory分配内存绕过JVM管理,这样做除了性能优势外,还有什么其他好处?这种方式是否存在风险?” 这个问题其实也和ClassLoader有关,如果不同的ClassLoader加载了同一个库的不同版本,可能会导致一些奇怪的问题。所以,规范依赖管理、使用统一的类加载策略也很重要。

这个问题在OSGi环境、应用服务器以及一些复杂的类加载环境中比较常见。通用的解决方案包括:合理规划类加载结构,避免重复加载;使用共享类加载器;使用工具分析和解决类冲突问题。

从文中看,感觉RocketMQ客户端存储消费者信息的方式比较冗余,或许可以考虑优化这部分的实现,减少内存占用。当然,这需要深入研究RocketMQ客户端的源码。

很多框架为了隔离依赖,都会使用独立的ClassLoader,如果应用中使用了多个类似的框架,就容易出现重复加载类的问题。解决方法可以考虑:选择依赖更少的框架;使用类加载器桥接,实现类共享。

这个其实也是一种取舍吧,就像C++用malloc一样,虽然可以更灵活地控制内存,但是也需要自己管理内存的释放,容易出问题。Netty这样做也是为了性能,但同时也增加了出错的风险,需要更小心地使用。

除了性能,我觉得更重要的是控制力。Netty可以通过这种方式更精细地控制内存分配和释放,例如实现内存池之类的机制,从而进一步提升性能。风险当然也有,最大的问题就是绕过了JVM的保护,如果Netty自身的内存管理出现问题,可能会导致更严重的 consequences。

RocketMQ客户端在处理大量消息,特别是大消息时,会使用较多的堆外内存。优化方法包括:调整客户端参数,例如减少批量拉取消息的数量;优化消息体大小;使用更高效的序列化方式。

除了消息大小和数量,客户端的连接数、网络状况等因素也会影响堆外内存的使用。优化可以考虑:使用连接池,减少频繁的连接创建和销毁;启用消息压缩,减少网络传输的数据量。