欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

MySQL OOM 系列三 摆脱MySQL被Kill的厄运

程序员文章站 2024-02-12 19:04:16
前面两章,我们分析了linux内存分配的策略以及linux通过使用 oom_killer的机制解决了“超售”引起的风险,mysql同其他的应用程序一样,在操作系统允许的范围...

前面两章,我们分析了linux内存分配的策略以及linux通过使用 oom_killer的机制解决了“超售”引起的风险,mysql同其他的应用程序一样,在操作系统允许的范围内也是可以超售的,一般人理解,innodb_buffer_pool必须小于实际物理内存,否则mysql会启动失败。其实这是一个误区,这个不是mysql层控制的,这个是操作系统(os)层控制的,就是前面提到的/proc/sys/overcommit_memory控制os是否允许“超售”。如果允许“超售”,则innodb_buffer_pool可以远远超过实际的内存空间大小,但是这部分空间是没有使用的。我们可以做个小实验,见下图:

MySQL OOM 系列三 摆脱MySQL被Kill的厄运

mysql的innodb_buffer_pool开了5g,但实际内存只有3g。
讲了这么多,现在言归正传,回到我们最早提到的rds实例被os kill掉的问题上来,前面我们也提到了,一旦实例可用内存不足,mysql一般都会成为oom_killer的首选目标。这里就涉及到两个问题:

1.为什么会内存不足?
2.如何让mysql摆脱被kill的厄运?
首先我们来看一下第一个问题。内存不足这个问题产生原因很多,但是主要就两个方面,第一个是mysql自身内存的规划有问题。第二个就是一般部署mysql的服务器,都会部署很多的监控或者定时任务脚本,而这些脚本往往缺少必要的内存限制,导致在高峰期的时候占用大量的内存,导致触发linux oom_killer机制,mysql就无辜牺牲了。
那如何才能让mysql摆脱被kill的厄运呢? mysql被kill的根源在于linux超售的内存分配机制,前面也提到了,只要存在这种超售的机制,就不可能完全避免某一个应用程序被kill的风险。那要使得mysql一定不会被kill掉,只能禁止操作系统超出实际内存空间的分配内存。但是前面我们也提过,对于部署了mysql的服务器,我们不建议这么做,因为mysql的很多内存都是刚开始申请了,并不是立即使用的,os一旦禁止超售,这不仅对mysql自身内存规划提出更苛刻的要求,同时也存在内存无法充分利用的问题。同时,mysql的每个连接的私有内存是动态分配的,如果分配不到,就会直接导致服务器crash,这样也会增加mysql crash的风险。
既然受限于操作系统,无法完全做到避免被kill,那只能尽量降低mysql被kill的几率。我觉得至少可以做下面3个事情:


1)合理的规划mysql的内存使用。
2)调整oom_adj参数,将mysql被oom_killer锁定的优先级降低。
3)加强内存的监控和报警,一旦报警,dba应该迅速介入,kill掉一些占用较多内存的连接。