最近經常有收到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 對這兩show engine innodb status; 5. 記錄MySQL 程序佔用大小;6 對這兩show次結果進行對比，主要看看在執行Flush table 前和Flush Table 後MySQL 分配的記憶體有沒有明顯的變化。 好吧， 這個bug 似乎不再我這裡。
看了一下這個版本有個innodb_buffer_pool_instances 參數，官網上也有關於innodb_buffer_pool_instances 和innodb_buffer_pool_size設定不當導致MySQL OOM 的bug ，大概的意思是：我們可以給我們實體記憶體設定值，例如我們實際記憶體設定：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如果不能訪問可以訪問(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
