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、内存增长图
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，也许能定位问题了