MySQL Slave 觸發 oom-killer處理辦法。本站提示廣大學習愛好者：（MySQL Slave 觸發 oom-killer處理辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是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假如不克不及拜訪可以拜訪(http://www.jb51.net/article/88729.htm)

最初略微總結一下：

景象：Slave OOM
暫時處理方法： 重啟Slave
歷久處理方法： 小版本進級 MySQL Server

更體系點的請看郭總寫的：
http://www.jb51.net/article/88726.htm
http://www.jb51.net/article/88727.htm