MySQL Slave 触发 oom-killer 原因分析

Posted xiepaup

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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。详细信息: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
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

 

我把稍微再具体点的东西记录到了这里:https://bugs.launchpad.net/percona-server/+bug/1560304

 

最后稍微总结一下:

    现象:Slave OOM

    临时解决办法: 重启Slave

    长期解决办法: 小版本升级 MySQL Server

 

更系统点的请看郭总写的:http://backend.blog.163.com/blog/static/202294126201371651930522/ 

                                  http://backend.blog.163.com/blog/static/20229412620137195534755/

 

以上是关于MySQL Slave 触发 oom-killer 原因分析的主要内容,如果未能解决你的问题,请参考以下文章

MySQL 主从复制,仅在从数据库(Slave)上存在的触发器(Trigger)不会被触发的问题解决

MySQL 主从复制,仅在从数据库(Slave)上存在的触发器(Trigger)不会被触发的问题解决

RK3399平台开发系列讲解(内存篇)18.6OOM触发机制

使用zabbix监控mysql主从状态

redis作为mysql的缓存服务器(读写分离,通过mysql触发器实现数据同步)

MySQL高可用主从复制新增slave