河北省网站建设公司排名,济南网站开发定制,企业客户管理系统软件,wordpress上传歌曲背景
最近准备上线cassandra这个产品#xff0c;同事在做一些小规格ECS(8G)的压测。压测时候比较容易触发OOM Killer#xff0c;把cassandra进程干掉。问题是8G这个规格我配置的heap(Xmx)并不高#xff08;约6.5g#xff09;已经留出了足够的空间给系统。只有可能是Java堆…背景
最近准备上线cassandra这个产品同事在做一些小规格ECS(8G)的压测。压测时候比较容易触发OOM Killer把cassandra进程干掉。问题是8G这个规格我配置的heap(Xmx)并不高约6.5g已经留出了足够的空间给系统。只有可能是Java堆外内存使用超出预期导致RES增加才可能触发OOM。
调查过程
0.初步怀疑是哪里有DirectBuffer泄漏或者JNI库的问题。 1.按惯例通过google perftools追踪堆外内存开销但是并未发现明显的异常。 2.然后用Java NMT 看了一下也没有发现什么异常。 3.查到这里思路似乎断了因为跟DirectBuffer似乎没啥关系。这时候我注意到进程虚拟内存非常高已经超过ECS内存了。怀疑这里有些问题。 4.进一步通过/proc/pid/smaps 查看进程内存地址空间分布发现有大量mmap的文件。这些文件是cassandra的数据文件。 此时这些mmap file 虚拟内存是2G但是物理内存是0因为我之前重启过调低过内存防止进程挂掉影响问题排查。
显然mmap的内存开销是不受JVM heap控制的也就是堆外内存。如果mmap的文件数据被从磁盘load进物理内存(RES增加)Java NMT和google perftool是无法感知的这是kernel的调度过程。
5.考虑到是在压测时候出现问题的所以我只要读一下这些文件观察下RES是否会增加增加多少为啥增加就能推断问题是不是在这里。通过下面的命令简单读一下之前导入的数据。
cassandra-stress read duration10m clONE -rate threads20 -mode native cql3 usercassandra password123 -schema keysp
acekeyspace5 -node core-3
6.可以观察到压测期间(sar -B)major page fault是明显上升的因为数据被实际从磁盘被load进内存。 同时观察到mmap file物理内存增加到20MB: 最终进程RES涨到7.1g左右增加了大约600M: 如果加大压力50线程还会涨每个mmap file物理内存会从20MB涨到40MB
7.Root cause是cassandra识别系统是64还是32来确定要不要用mmapECS都是64但是实际上小规格ECS内存并不多。 结论
1.问题诱因是mmap到内存开销没有考虑进去具体调整方法有很多。可以针对小规格ECS降低heap配置或者关闭mmap特性(disk_access_modestandard) 2.排查Java堆外内存还是比较麻烦的推荐先用NMT查查用起来比较简单配置JVM参数即可可以看到内存申请情况。
原文链接 本文为云栖社区原创内容未经允许不得转载。
