MYSQL数据库MySQL Slave 触发 oom-killer解决方法

《MYSQL数据库MySQL Slave 触发 oom-killer解决方法》要点：
本文介绍了MYSQL数据库MySQL Slave 触发 oom-killer解决方法，希望对您有用。如果有疑问，可以联系我们。

最近经常有收到MySQL实例类似内存不敷的报警信息,登陆到服务器上一看发现MySQL 吃掉了99%的内存,God !MYSQL数据库

有时候没有及时处理,内核就会本身帮我们重启下MySQL,然后我们就可以看到 dmesg 信息有如下记录：MYSQL数据库

Mar 9 11:29:16 xxxxxx kernel: mysqld invoked oom-killer: gfp_mask=0x201da,order=0,oom_adj=0,oom_score_adj=0
Mar 9 11:29:16 xxxxxx kernel: mysqld cpuset=/ mems_allowed=0
Mar 9 11:29:16 xxxxxx kernel: Pid: 99275,comm: mysqld Not tainted 2.6.32-431.el6.x86_64 #1
Mar 9 11:29:16 xxxxxx kernel: Call Trace:MYSQL数据库

现描写一下具体场景吧：MYSQL数据库

年夜前提 ： 操作系统以及MySQL 版本：MYSQL数据库

OS ： CentOS release 6.5 (Final) Kernel : 2.6.32-431.el6.x86_64(物理机)
MySQL : Percona 5.6.23-72.1-log(单实例)MYSQL数据库

触发场景：Slave 不管是否有其它链接进来都会出现内存周期性的暴涨,触发内核oom-killer

据说这个问题都出现了1年多了,由于刚过来,老大就让我再查查看能不克不及找到什么蛛丝马迹,那么就开始Check 这个问题咯：MYSQL数据库

1. 怀疑给MySQL 分配的内存不合理,那么我就去check 了一下 innodb_buffer_pool 的大小 和物理内存的大小,发现分配给BP的大小占物理内存的60%左右,那么不是这个原因,排除掉,要是是这个问题它们也应该早就发现了～
2. 检查操作系统各项参数配置.[vm.swappiness = 1 ; /proc/sys/vm/overcommit_memory ; oom_adj ] 在没排查到问题前可以临时设置一下 adj参数 给个 －15 或者直接 －17,这样内核就永远不会kill 掉 mysql了,但是这样做不能根本解决问题,而且存在一定的风险,会不会导致MySQL 需要内存又分配不出来而hang住呢? 这个方法就想想算了吧.
3. 好吧,mysql初始化参数、操作系统参数看起来没什么配置有不恰当的地方.那我们就来找找MySQL 本身的吧!MYSQL数据库

既然MySQL 内存一直处于在飙升的状态,那么,会不会是由于内存分配的时候导致的呢,那么根据网上报了一个MySQL 内存分配引起的一个Bug,我也来在我这个环境操作一把,一看毕竟：1.记录当前 MySQL 进程占用的 内存大小；2.记录 show engine innodb status ; 3. 执行 flush tables; 4.记录 show engine innodb status; 5. 记录 MySQL 进程占用大小;6 对这两次结果进行对比,主要看看在执行Flush table 前 和 Flush Table 后MySQL 分配的内存有没有明显的变化. 好吧,这个bug 貌似不再我这里.MYSQL数据库

看了一下这个版本有个 innodb_buffer_pool_instances 参数,官网上也有关于innodb_buffer_pool_instances 和 innodb_buffer_pool_size设置不当 导致MySQL OOM 的 bug,大概的意思就是：我们可以给innodb_buffer_pool_size 设置的比我们实际物理内存要大,好比我们物理内存是：64GB,而我们设置 innodb_buffer_pool_size＝300GB,并且把 innodb_buffer_pool_instances > 5,我们就依旧可以把MySQL 拉起来.但是呢,这样MySQL很容易OOM.详细信息：http://bugs.mysql.com/bug.php?id=79850 这里看过来.MYSQL数据库

还有种情况,也报过BUG,便是 slave 设置过滤的时候,也会触发OOM,but 我这些个 Instance 没有设置,所以就 忽略这点咯.MYSQL数据库

既然不是MySQL内存超售引起,也不是 打开表的句柄导致.那么还有什么原因呢?MYSQL数据库

我们再想想,这个现象出现在Slave,Master 和Slave 配置一样,只是Master 上跑了生产业务,Slave 上有些Instance 跑了查询业务,有些Instance 根本就没有跑任何任务,但是还是会出发OOM,那么这种情况很可能便是 Slave 引起的蕖MYSQL数据库

那我就找了个实例上去试了一把,不试不知道啊,一试吓一跳.上去执行了一下：stop slave;start slave;这个命令卡了大概3分钟,再一看内存使用情况,一下子释放出来了20GB＋. 到这里基本上算是定位到了问题所在了,但是Slave 我们都知道有两个线程,到底是由于SQL Thread 还是 IO Thread 导致的呢? 这个还的等待下次即将产生时在进一步排查了.MYSQL数据库

贴点内存的监控信息：MYSQL数据库

12:00:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit
02:40:01 PM 566744 131479292 99.57 88744 618612 132384348 89.19
02:50:01 PM 553252 131492784 99.58 83216 615068 132406792 89.20
03:00:01 PM 39302700 92743336 70.24 95908 925860 132413308 89.21
03:10:01 PM 38906360 93139676 70.54 109264 1292908 132407836 89.21
03:20:01 PM 38639536 93406500 70.74 120676 1528272 132413136 89.21MYSQL数据库

我把稍微再具体点的东西记录到了这里：https://bugs.launchpad.net/percona-server/+bug/1560304如果不能拜访可以拜访(/article/88729.htm)MYSQL数据库

末了稍微总结一下：MYSQL数据库

现象：Slave OOM
临时解决方法： 重启Slave
长期解决方法： 小版本升级 MySQL ServerMYSQL数据库

更体系点的请看郭总写的：
/article/88726.htm
/article/88727.htmMYSQL数据库

编程之家PHP培训学院每天发布《MYSQL数据库MySQL Slave 触发 oom-killer解决方法》等实战技能，PHP、MYSQL、LINUX、APP、JS,CSS全面培养人才。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!