性能问答>RSS内存急速增长并高于NMT内存>
4回复
9月前

RSS内存急速增长并高于NMT内存



现象:8.13日早在无业务的情况下,内存突增2.4g左右,进入容器内查看,rss 4.3g,java nmt 内存1.8g committed,通过gdb dump pmap中不在nmt的内存,分析发现乱码,无明显业务特征
环境:跑在阿里云ACK上,java版本 openjdk version “11.0.9.1”,ARMS版本arms-bootstrap-1.7.0-SNAPSHOT.jar
相关资料
1、内存增长图
image.png
2、NMT数据nmt_online

3、gdb dump内存(pmap后找到不在nmt的内存)
gdb_online.zip

求助排查手段和解决思路

859 阅读
请先登录,再评论

1.问题的理解
Pod内存在9:10左右从2G增加到4.2G。
从NMT报告来看,Total: reserved=4900534KB, committed=1835682KB。
可以看出Pod内存占用和Reserved值比较接近,而committed是进程实际使用了的。
所以真正的问题,是要定位9:10这个时间,进程发生了什么,导致RSS内存增长,为什么commited内存不大(应该是后面释放了内存)。

2.从NMT数据来看,可以看出主要是Java Heap/Class/Thread这3部分多出来的
Total: reserved=4900534KB, committed=1835682KB,Reserved多3.1G
Java Heap (reserved=2097152KB, committed=1102848KB) Reserved多0.9G
Class (reserved=1274612KB, committed=260408KB) Reserved多1.0G
Thread (reserved=995573KB, committed=114797KB) Reserved多0.9G

结合监控数据来看,可能是在9:10左右进程大量创建Thread,所以Heap/Class/Thread内存增加。
然后短时间又释放了,committed恢复,但Reserved内存仍维持增长后的情况。
(不确定reserved/committed的联系,上面只是猜测)

3.建议排查思路
如果问题能复现的话:
1)监控下JVM线程变化情况,取RSS变化前后的heap dump,对比分析下线程变化情况
2)记录gc日志,用于辅助内存分析
如果能找出突然创建又销毁的thread,也许能定位问题了

19月前
回复 常越峰:

非堆内存,在NMT报告中就是这些吧:Class+Thread+Code+GC+Compiler+Internal+Other+Symbol,reserved之和是2.4G左右。
如果问题还可以复现的话,可以在内存变化前后分别取NMT报告,然后比对一下看哪一部分内存有变化,也许对定位原因有帮助。

9月前回复
回复 鱼沙:

看了下历史监控,线程数是没有变化的,所以应该不是这个引起~ 🙏

9月前回复
回复 鱼沙:

感谢回复,不过我这边部分理解是不一样的
1、非堆内存的判断:从现状来看,pod内内存依然使用着4.2g的空间没有释放,而且pmap中(对比NMT),堆内部分是对应上的,非堆部分确实是N个64M内存块(总计2.4g)。所以从这块来看,应该和heap没有太大关系,自然gc的日志也没太大关系(手动触发过fullgc也无法回收多的2.4g内存)
2、线程部分,目前该模块稳定线程数是900+,如果是创建销毁的话,应该能看到内存的波动情况(虽然打点是一分钟一次),但实际来看,突增内存前内存监控是平稳的,突增内存后,内存监控也是平稳的。

目前我们这边尝试采取strace等手段定位内存申请的线程栈,但因为是偶发还没抓到。另外线程数监控也是一个好的线索,感谢回复Thanks♪(・ω・)ノ

9月前回复