《MYSQL數(shù)據(jù)庫MySQL Slave 觸發(fā) oom-killer解決方法》要點(diǎn)：
本文介紹了MYSQL數(shù)據(jù)庫MySQL Slave 觸發(fā) oom-killer解決方法，希望對您有用。如果有疑問，可以聯(lián)系我們。

最近經(jīng)常有收到MySQL實(shí)例類似內(nèi)存不敷的報(bào)警信息,登陸到服務(wù)器上一看發(fā)現(xiàn)MySQL 吃掉了99%的內(nèi)存,God !MYSQL數(shù)據(jù)庫

有時(shí)候沒有及時(shí)處理,內(nèi)核就會本身幫我們重啟下MySQL,然后我們就可以看到 dmesg 信息有如下記錄：MYSQL數(shù)據(jù)庫

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數(shù)據(jù)庫

現(xiàn)描寫一下具體場景吧：MYSQL數(shù)據(jù)庫

年夜前提 ： 操作系統(tǒng)以及MySQL 版本：MYSQL數(shù)據(jù)庫

OS ： CentOS release 6.5 (Final) Kernel : 2.6.32-431.el6.x86_64(物理機(jī))
MySQL : Percona 5.6.23-72.1-log(單實(shí)例)MYSQL數(shù)據(jù)庫

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

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

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

既然MySQL 內(nèi)存一直處于在飆升的狀態(tài),那么,會不會是由于內(nèi)存分配的時(shí)候?qū)е碌哪?那么根據(jù)網(wǎng)上報(bào)了一個(gè)MySQL 內(nèi)存分配引起的一個(gè)Bug,我也來在我這個(gè)環(huán)境操作一把,一看畢竟：1.記錄當(dāng)前 MySQL 進(jìn)程占用的 內(nèi)存大小；2.記錄 show engine innodb status ; 3. 執(zhí)行 flush tables; 4.記錄 show engine innodb status; 5. 記錄 MySQL 進(jìn)程占用大小;6 對這兩次結(jié)果進(jìn)行對比,主要看看在執(zhí)行Flush table 前 和 Flush Table 后MySQL 分配的內(nèi)存有沒有明顯的變化. 好吧, 這個(gè)bug 貌似不再我這里.MYSQL數(shù)據(jù)庫

看了一下這個(gè)版本有個(gè) innodb_buffer_pool_instances 參數(shù),官網(wǎng)上也有關(guān)于innodb_buffer_pool_instances 和 innodb_buffer_pool_size設(shè)置不當(dāng) 導(dǎo)致MySQL OOM 的 bug ,大概的意思就是：我們可以給innodb_buffer_pool_size 設(shè)置的比我們實(shí)際物理內(nèi)存要大,好比我們物理內(nèi)存是：64GB,而我們設(shè)置 innodb_buffer_pool_size＝300GB,并且把 innodb_buffer_pool_instances > 5 ,我們就依舊可以把MySQL 拉起來.但是呢, 這樣MySQL很容易OOM.詳細(xì)信息：http://bugs.mysql.com/bug.php?id=79850 這里看過來.MYSQL數(shù)據(jù)庫

還有種情況,也報(bào)過BUG,便是 slave 設(shè)置過濾的時(shí)候,也會觸發(fā)OOM ,but 我這些個(gè) Instance 沒有設(shè)置, 所以就 忽略這點(diǎn)咯.MYSQL數(shù)據(jù)庫

既然不是MySQL內(nèi)存超售引起,也不是 打開表的句柄導(dǎo)致.那么還有什么原因呢?MYSQL數(shù)據(jù)庫

我們再想想,這個(gè)現(xiàn)象出現(xiàn)在Slave,Master 和Slave 配置一樣, 只是Master 上跑了生產(chǎn)業(yè)務(wù),Slave 上有些Instance 跑了查詢業(yè)務(wù),有些Instance 根本就沒有跑任何任務(wù),但是還是會出發(fā)OOM,那么這種情況很可能便是 Slave 引起的蕖MYSQL數(shù)據(jù)庫

那我就找了個(gè)實(shí)例上去試了一把, 不試不知道啊, 一試嚇一跳.上去執(zhí)行了一下：stop slave;start slave;這個(gè)命令卡了大概3分鐘,再一看內(nèi)存使用情況,一下子釋放出來了20GB＋. 到這里基本上算是定位到了問題所在了,但是Slave 我們都知道有兩個(gè)線程,到底是由于SQL Thread 還是 IO Thread 導(dǎo)致的呢? 這個(gè)還的等待下次即將產(chǎn)生時(shí)在進(jìn)一步排查了.MYSQL數(shù)據(jù)庫

貼點(diǎn)內(nèi)存的監(jiān)控信息：MYSQL數(shù)據(jù)庫

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.21MYSQL數(shù)據(jù)庫

我把稍微再具體點(diǎn)的東西記錄到了這里：https://bugs.launchpad.net/percona-server/+bug/1560304如果不能拜訪可以拜訪(/article/88729.htm)MYSQL數(shù)據(jù)庫

末了稍微總結(jié)一下：MYSQL數(shù)據(jù)庫

現(xiàn)象：Slave OOM
臨時(shí)解決方法： 重啟Slave
長期解決方法： 小版本升級 MySQL ServerMYSQL數(shù)據(jù)庫

更體系點(diǎn)的請看郭總寫的：
/article/88726.htm
/article/88727.htmMYSQL數(shù)據(jù)庫

維易PHP培訓(xùn)學(xué)院每天發(fā)布《MYSQL數(shù)據(jù)庫MySQL Slave 觸發(fā) oom-killer解決方法》等實(shí)戰(zhàn)技能，PHP、MYSQL、LINUX、APP、JS,CSS全面培養(yǎng)人才。

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/9513.html