8G的容器Java堆才4G怎么就OOM了?

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

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


背景

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

image.png

 image.png

初步收集到的信息:

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

image.png

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

image.png

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


问题结论

省流版

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

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

image.png

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

image.png


详细版

中间件中多个不同的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个。

image.png

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


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

image.png


排查过程

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

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

image.png

明明是限制的堆外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

image.png

内存里面装了什么

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

image.png

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


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


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

image.png

image.png

如图所示,发现里面大量的内容都和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,以及机器上启动过程中打印出的信息。

image.png

结合这里面涉及的另一个核心类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

image.png

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


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

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


image.png



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


1.5.业务应该怎么做呢

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


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


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


后记

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





来源  |  阿里云开发者公众号

作者  |  熹正

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
5月前
|
缓存 JavaScript Java
常见java OOM异常分析排查思路分析
Java虚拟机(JVM)遇到内存不足时会抛出OutOfMemoryError(OOM)异常。常见OOM情况包括:1) **Java堆空间不足**:大量对象未被及时回收或内存泄漏;2) **线程栈空间不足**:递归过深或大量线程创建;3) **方法区溢出**:类信息过多,如CGLib代理类生成过多;4) **本机内存不足**:JNI调用消耗大量内存;5) **GC造成的内存不足**:频繁GC但效果不佳。解决方法包括调整JVM参数(如-Xmx、-Xss)、优化代码及使用高效垃圾回收器。
238 15
常见java OOM异常分析排查思路分析
|
6月前
|
Kubernetes Cloud Native Java
云原生之旅:从容器到微服务的演进之路Java 内存管理:垃圾收集器与性能调优
【8月更文挑战第30天】在数字化时代的浪潮中,企业如何乘风破浪?云原生技术提供了一个强有力的桨。本文将带你从容器技术的基石出发,探索微服务架构的奥秘,最终实现在云端自由翱翔的梦想。我们将一起见证代码如何转化为业务的翅膀,让你的应用在云海中高飞。
|
6月前
|
存储 算法 Java
惊!Java程序员必看:JVM调优揭秘,堆溢出、栈溢出如何巧妙化解?
【8月更文挑战第29天】在Java领域,JVM是代码运行的基础,但需适当调优以发挥最佳性能。本文探讨了JVM中常见的堆溢出和栈溢出问题及其解决方法。堆溢出发生在堆空间不足时,可通过增加堆空间、优化代码及释放对象解决;栈溢出则因递归调用过深或线程过多引起,调整栈大小、优化算法和使用线程池可有效应对。通过合理配置和调优JVM,可确保Java应用稳定高效运行。
173 4
|
6月前
|
存储 算法 Java
解释 Java 堆空间和垃圾收集
【8月更文挑战第22天】
47 0
|
2月前
|
存储 算法 Java
Java 内存管理与优化:掌控堆与栈,雕琢高效代码
Java内存管理与优化是提升程序性能的关键。掌握堆与栈的运作机制,学习如何有效管理内存资源,雕琢出更加高效的代码,是每个Java开发者必备的技能。
93 5
|
3月前
|
安全 Java 编译器
Java对象一定分配在堆上吗?
本文探讨了Java对象的内存分配问题,重点介绍了JVM的逃逸分析技术及其优化策略。逃逸分析能判断对象是否会在作用域外被访问,从而决定对象是否需要分配到堆上。文章详细讲解了栈上分配、标量替换和同步消除三种优化策略,并通过示例代码说明了这些技术的应用场景。
Java对象一定分配在堆上吗?
|
4月前
|
存储 算法 Java
🏗️Java零基础:深入了解Java 堆
【10月更文挑战第2天】本文收录于「滚雪球学Java」专栏,专业攻坚指数级提升,希望能够助你一臂之力,帮你早日登顶实现财富自由🚀;同时,欢迎大家关注&&收藏&&订阅!持续更新中,up!up!up!!
45 3
|
5月前
|
缓存 JavaScript Java
常见java OOM异常分析排查思路分析
Java虚拟机(JVM)遇到 OutOfMemoryError(OOM)表示内存资源不足。常见OOM情况包括:1) **Java堆空间不足**:内存被大量对象占用且未及时回收,或内存泄漏;解决方法包括调整JVM堆内存大小、优化代码及修复内存泄漏。2) **线程栈空间不足**:单线程栈帧过大或频繁创建线程;可通过优化代码或调整-Xss参数解决。3) **方法区溢出**:运行时生成大量类导致方法区满载;需调整元空间大小或优化类加载机制。4) **本机内存不足**:JNI调用或内存泄漏引起;需检查并优化本机代码。5) **GC造成的内存不足**:频繁GC但效果不佳;需优化JVM参数、代码及垃圾回收器
142 7
常见java OOM异常分析排查思路分析
|
5月前
|
JSON 前端开发 JavaScript
java中post请求调用下载文件接口浏览器未弹窗而是返回一堆json,为啥
客户端调接口需要返回另存为弹窗,下载文件,但是遇到的问题是接口调用成功且不报错,浏览器F12查看居然返回一堆json,而没有另存为弹窗; > 正确的效果应该是:接口调用成功且浏览器F12不返回任何json,而是弹窗另存为窗口,直接保存文件即可。
211 2
|
4月前
|
存储 算法 Java
【用Java学习数据结构系列】用堆实现优先级队列
【用Java学习数据结构系列】用堆实现优先级队列
54 0

热门文章

最新文章