MySQL Slave 触发 oom-killer解决方法

最近经常有收到mysql实例类似内存不足的报警信息，登陆到服务器上一看发现mysql 吃掉了99%的内存，god ！

有时候没有及时处理，内核就会自己帮我们重启下mysql，然后我们就可以看到 dmesg 信息有如下记录：

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 版本：

os ： centos release 6.5 (final) kernel : 2.6.32-431.el6.x86_64（物理机）
mysql : percona 5.6.23-72.1-log（单实例）

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

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

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 内存分配引起的一个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 貌似不再我这里。

看了一下这个版本有个 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。详细信息： 这里看过来。

还有种情况，也报过bug，就是 slave 设置过滤的时候，也会触发oom ，but 我这些个 instance 没有设置， 所以就 忽略这点咯。

既然不是mysql内存超售引起，也不是 打开表的句柄导致。那么还有什么原因呢？

我们再想想，这个现象出现在slave，master 和slave 配置一样， 只是master 上跑了生产业务，slave 上有些instance 跑了查询业务，有些instance 根本就没有跑任何任务，但是还是会出发oom，那么这种情况很可能就是 slave 引起的囖。

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

贴点内存的监控信息：

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.21

我把稍微再具体点的东西记录到了这里：如果不能访问可以访问()

最后稍微总结一下：

现象：slave oom
临时解决办法： 重启slave
长期解决办法： 小版本升级 mysql server

更系统点的请看郭总写的：