最近经常有收到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内存超售引起，也不是 打开表的句柄导致。那么还有什么原因呢？
法语写作助手
法语助手旗下的AI智能写作平台，支持语法、拼写自动纠错，一键改写、润色你的法语作文。
31 查看详情 
我们再想想，这个现象出现在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如果不能访问可以访问(http://www.bitsCN.com/article/88729.htm)
最后稍微总结一下：
现象：Slave OOM
临时解决办法： 重启Slave
长期解决办法： 小版本升级 MySQL Server
更系统点的请看郭总写的：
http://www.bitsCN.com/article/88726.htm
http://www.bitsCN.com/article/88727.htm
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/427899.html
微信扫一扫 
支付宝扫一扫 
