Cassandra 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 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进内存。
同时观察到mmap file物理内存增加到20MB:
最终进程RES涨到7.1g左右,增加了大约600M:
如果加大压力(50线程),还会涨,每个mmap file物理内存会从20MB,涨到40MB
7.Root cause是cassandra识别系统是64还是32来确定要不要用mmap,ECS都是64,但是实际上小规格ECS内存并不多。
结论
1.问题诱因是mmap到内存开销没有考虑进去,具体调整方法有很多。可以针对小规格ECS降低heap配置或者关闭mmap特性(disk_access_mode=standard)
2.排查Java堆外内存还是比较麻烦的,推荐先用NMT查查,用起来比较简单,配置JVM参数即可,可以看到内存申请情况。
作者:Roin
原文链接
本文为云栖社区原创内容,未经允许不得转载。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【spring cloud hoxton】Ribbon 真的能被 spring-cloud-loadbalancer 替代吗
背景 早上刷圈看到 Spring Cloud Hoxton.M2 Released 的消息,随手发布到了我的知识星球,过了会有个朋友过来如下问题。 抽取半天时间学习spring-cloud-loadbalancer 的源码,整理出此文总结 Spring Cloud Hoxton.M2 是第一个整合新的loadbalancer实现来替代Ribbon的版本 Spring Cloud Hoxton.M2 is the first release containing both blocking and non-blocking load balancer client implementations as an alternative to Netflix Ribbon which has entered maintenance mode. spring-cloud-loadbalancer 的渊源 2017年spring 开始尝试开发新的项目 spring-cloud-loadbalancer 替代ribbon,项目托管在 spring-cloud-incubator 孵化器 (多提一嘴,...
- 下一篇
从求生存到修体系,我在阿里找到了技术人的成长模式
阿里妹导读:做业务就好比打仗,团队是我们的归属。在团队中,我们既要通力协作,又要定义问题,既要业务先赢,又要技术成长。越来越多的前端投身业务研发中。想要有更好的发展,业务理解力非常关键。阿里巴巴前端技术专家悟寻将他在阿里的成长思考,送给在业务中深耕细作的你。 前言 我将我经历过的或者正在经历的状态,分成三个阶段进行总结:求生存,谋发展,修体系。 阶段一:埋头苦干求生存 作为一个服务一线业务的前端同学,支撑好业务占据我们50%-60%左右的KPI,纵观行业前端本身很容易成为整个业务的资源瓶颈,而身为业务的前端我相信一定经历过疲于奔命,经常线上救火的事情。我入职后的前一年主要做进口业务:天猫国际,一个包含平台和自营的业务。当时的进口业务还处于野蛮生长,竞争激烈的阶段。经常面临一年两大改,日常需求不断,期间还要应付一年的5个S级的大促和一些小促,我记得最忙的时候是17年双十一,面临着自营和平台两块业务的大迭代,同时还需要面临双十一大促各种需求,每天除了做业务几乎没有什么思考和总结的过程。而经过那次之后我也深刻体会到对于需求管理和时间管理 & 如何避免避免线上起火的重要性。这里我结合自...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8安装Docker,最新的服务器搭配容器使用
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7安装Docker,走上虚拟化容器引擎之路