开发者社区> 只会写BUG> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

记一次Cassandra Java堆外内存排查经历

简介: 背景 最近准备上线cassandra这个产品,同事在做一些小规格ECS(8G)的压测。压测时候比较容易触发OOM Killer,把cassandra进程干掉。问题是8G这个规格我配置的heap(Xmx)并不高(约6.5g)已经留出了足够的空间给系统。
+关注继续查看

背景

最近准备上线cassandra这个产品,同事在做一些小规格ECS(8G)的压测。压测时候比较容易触发OOM Killer,把cassandra进程干掉。问题是8G这个规格我配置的heap(Xmx)并不高(约6.5g)已经留出了足够的空间给系统。只有可能是Java堆外内存使用超出预期,导致RES增加,才可能触发OOM。

调查过程

0.初步怀疑是哪里有DirectBuffer泄漏,或者JNI库的问题。
1.按惯例通过google perftools追踪堆外内存开销,但是并未发现明显的异常。
2.然后用Java NMT 看了一下,也没有发现什么异常。
0e964369341ad29ff6ea1e20ea75f0d3ed8e963f

3.查到这里思路似乎断了,因为跟DirectBuffer似乎没啥关系。这时候我注意到进程虚拟内存非常高,已经超过ECS内存了。怀疑这里有些问题。
ab6a0b6198cf86c4de8eac020f0c472564241cb8

4.进一步通过/proc/pid/smaps 查看进程内存地址空间分布,发现有大量mmap的文件。这些文件是cassandra的数据文件。
956c61ef2bcd58ba40d0f498350619730ee14a26

此时这些mmap file 虚拟内存是2G,但是物理内存是0(因为我之前重启过,调低过内存防止进程挂掉影响问题排查)。

显然mmap的内存开销是不受JVM heap控制的,也就是堆外内存。如果mmap的文件数据被从磁盘load进物理内存(RES增加),Java NMT和google perftool是无法感知的,这是kernel的调度过程。

5.考虑到是在压测时候出现问题的,所以我只要读一下这些文件,观察下RES是否会增加,增加多少,为啥增加,就能推断问题是不是在这里。通过下面的命令简单读一下之前导入的数据。

cassandra-stress read duration=10m cl=ONE -rate threads=20 -mode native cql3 user=cassandra password=123 -schema keysp
ace=keyspace5 -node core-3

6.可以观察到压测期间(sar -B),major page fault是明显上升的,因为数据被实际从磁盘被load进内存。
4944c8972d4df6a173c805cf7d5e91aa6049c49f

同时观察到mmap file物理内存增加到20MB:
3751993b8ffc483ab37658181e40585a685b0d06

最终进程RES涨到7.1g左右,增加了大约600M:
2c56dc8fad29d7266a6e67ca6601d319c6914b76

如果加大压力(50线程),还会涨,每个mmap file物理内存会从20MB,涨到40MB

7.Root cause是cassandra识别系统是64还是32来确定要不要用mmap,ECS都是64,但是实际上小规格ECS内存并不多。
27b11488d70f5a5d36d0d5ff6af8c706b1578e46

结论

1.问题诱因是mmap到内存开销没有考虑进去,具体调整方法有很多。可以针对小规格ECS降低heap配置或者关闭mmap特性(disk_access_mode=standard)
2.排查Java堆外内存还是比较麻烦的,推荐先用NMT查查,用起来比较简单,配置JVM参数即可,可以看到内存申请情况。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Java内存模型之可见性
Java内存模型之可见性
18 0
Java内存模型之可见性
Java内存模型之可见性
19 0
Java线程安全以及线程安全的实现方式和内存模型(JMM)(2)
Java线程安全以及线程安全的实现方式和内存模型(JMM)(2)
28 0
Java线程安全以及线程安全的实现方式和内存模型(JMM)(1)
Java线程安全以及线程安全的实现方式和内存模型(JMM)(1)
36 0
Java 的流毒
本文讲的是Java 的流毒,这是因为他们两个都有相同的 JVM 签名。这不是 Kotlin 的问题,而是将他们编译成 Java 字节码的结果。这只是 Java 的流毒影响 Kotlin 执行的一种方式。但是这里还有更大的问题。
1032 0
+关注
只会写BUG
郭泽晖,花名索月,目前就职于阿里云数据库团队。HBase&Cassandra contributor,热爱算法与开源技术。
11
文章
43
问答
来源圈子
更多
相关文档: 云数据库Cassandra
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载