最近經常有收到MySQL實例類似內存不足的報警信息，登陸到服務器上一看發(fā)現(xiàn)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:

現(xiàn)描述一下具體場景吧：

大前提 ： 操作系統(tǒng)以及MySQL 版本：

OS ： CentOS release 6.5 (Final) Kernel : 2.6.32-431.el6.x86_64（物理機）
MySQL : Percona 5.6.23-72.1-log（單實例）

觸發(fā)場景：Slave 不管是否有其它鏈接進來都會出現(xiàn)內存周期性的暴漲，觸發(fā)內核oom-killer

據(jù)說這個問題都出現(xiàn)了1年多了，由于剛過來，老大就讓我再查查看能不能找到什么蛛絲馬跡，那么就開始Check 這個問題咯：

1. 懷疑給MySQL 分配的內存不合理，那么我就去check 了一下 innodb_buffer_pool 的大小 和物理內存的大小，發(fā)現(xiàn)分配給BP的大小占物理內存的60%左右，那么不是這個原因， 排除掉，要是是這個問題它們也應該早就發(fā)現(xiàn)了～
2. 檢查操作系統(tǒng)各項參數(shù)配置。[vm.swappiness = 1 ; /proc/sys/vm/overcommit_memory ; oom_adj ] 在沒排查到問題前可以臨時設置一下 adj參數(shù) 給個 －15 或者直接 －17，這樣內核就永遠不會kill 掉 mysql了， 但是這樣做不能根本解決問題， 而且存在一定的風險， 會不會導致MySQL 需要內存又分配不出來而hang住呢？ 這個辦法就想想算了吧。
3. 好吧，mysql初始化參數(shù)、操作系統(tǒng)參數(shù)看起來沒什么配置有不恰當?shù)牡胤健Ｄ俏覀兙蛠碚艺襇ySQL 本身的吧！

既然MySQL 內存一直處于在飆升的狀態(tài)，那么，會不會是由于內存分配的時候導致的呢，那么根據(jù)網上報了一個MySQL 內存分配引起的一個Bug，我也來在我這個環(huán)境操作一把，一看究竟：1.記錄當前 MySQL 進程占用的 內存大小；2.記錄 show engine innodb status ; 3. 執(zhí)行 flush tables; 4.記錄 show engine innodb status; 5. 記錄 MySQL 進程占用大小;6 對這兩次結果進行對比，主要看看在執(zhí)行Flush table 前 和 Flush Table 后MySQL 分配的內存有沒有明顯的變化。 好吧， 這個bug 貌似不再我這里。

看了一下這個版本有個 innodb_buffer_pool_instances 參數(shù)，官網上也有關于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 這里看過來。