MySQL Slave 触发 oom-killer解决方法
最近经常有收到MySQL实例类似内存不足的报警信息,登陆到服务器上一看发现MySQL吃掉了99%的内存,God!
有时候没有及时处理,内核就会自己帮我们重启下MySQL,然后我们就可以看到dmesg信息有如下记录:
Mar911:29:16xxxxxxkernel:mysqldinvokedoom-killer:gfp_mask=0x201da,order=0,oom_adj=0,oom_score_adj=0
Mar911:29:16xxxxxxkernel:mysqldcpuset=/mems_allowed=0
Mar911:29:16xxxxxxkernel:Pid:99275,comm:mysqldNottainted2.6.32-431.el6.x86_64#1
Mar911:29:16xxxxxxkernel:CallTrace:
现描述一下具体场景吧:
大前提:操作系统以及MySQL版本:
OS:CentOSrelease6.5(Final)Kernel:2.6.32-431.el6.x86_64(物理机)
MySQL:Percona5.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.记录showengineinnodbstatus;3.执行flushtables;4.记录showengineinnodbstatus;5.记录MySQL进程占用大小;6对这两次结果进行对比,主要看看在执行Flushtable前和FlushTable后MySQL分配的内存有没有明显的变化。好吧,这个bug貌似不再我这里。
看了一下这个版本有个innodb_buffer_pool_instances参数,官网上也有关于innodb_buffer_pool_instances和innodb_buffer_pool_size设置不当导致MySQLOOM的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引起的囖。
那我就找了个实例上去试了一把,不试不知道啊,一试吓一跳。上去执行了一下:stopslave;startslave;这个命令卡了大概3分钟,再一看内存使用情况,一下子释放出来了20GB+。到这里基本上算是定位到了问题所在了,但是Slave我们都知道有两个线程,到底是由于SQLThread还是IOThread导致的呢?这个还的等待下次即将发生时在进一步排查了。
贴点内存的监控信息:
12:00:01PMkbmemfreekbmemused%memusedkbbufferskbcachedkbcommit%commit
02:40:01PM56674413147929299.578874461861213238434889.19
02:50:01PM55325213149278499.588321661506813240679289.20
03:00:01PM393027009274333670.249590892586013241330889.21
03:10:01PM389063609313967670.54109264129290813240783689.21
03:20:01PM386395369340650070.74120676152827213241313689.21
我把稍微再具体点的东西记录到了这里:https://bugs.launchpad.net/percona-server/+bug/1560304如果不能访问可以访问(https://www.nhooo.com/article/88729.htm)
最后稍微总结一下:
现象:SlaveOOM
临时解决办法:重启Slave
长期解决办法:小版本升级MySQLServer
更系统点的请看郭总写的:
https://www.nhooo.com/article/88726.htm
https://www.nhooo.com/article/88727.htm