MySQL Slave 触发 oom-killer解决方法 |
|
本文标签：mysql,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 现描述一下具体场景吧： 大前提 ： 操作系统以及MySQL 版本： OS ： CentOS release 6.5 (Final) Kernel : 2.6.32-431.el6.x86_64（物理机） 触发场景：Slave 不管是否有其它链接进来都会出现内存周期性的暴涨，触发内核oom-killer 1. 怀疑给MySQL 分配的内存不合理，那么我就去check 了一下 innodb_buffer_pool 的大小 和物理内存的大小，发现分配给BP的大小占物理内存的60%左右，那么不是这个原因， 排除掉，要是是这个问题它们也应该早就发现了～ 既然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 。详细信息：http://bugs.mysql.com/bug.php?id=79850 这里看过来 。 还有种情况，也报过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 我把稍微再具体点的东西记录到了这里：https://bugs.launchpad.net/percona-server/+bug/1560304如果不能访问可以访问(http://www.jb51.net/article/88729.htm) 最后稍微总结一下： 现象：Slave OOM 更系统点的请看郭总写的： |
