前面兩章，我們分析了Linux內(nèi)存分配的策略以及Linux通過使用 OOM_Killer的機(jī)制解決了“超售”引起的風(fēng)險(xiǎn)，MySQL同其他的應(yīng)用程序一樣，在操作系統(tǒng)允許的范圍內(nèi)也是可以超售的，一般人理解，Innodb_buffer_pool必須小于實(shí)際物理內(nèi)存，否則MySQL會(huì)啟動(dòng)失敗。其實(shí)這是一個(gè)誤區(qū)，這個(gè)不是MySQL層控制的，這個(gè)是操作系統(tǒng)（OS）層控制的，就是前面提到的/proc/sys/overcommit_memory控制OS是否允許“超售”。如果允許“超售”，則Innodb_buffer_pool可以遠(yuǎn)遠(yuǎn)超過實(shí)際的內(nèi)存空間大小，但是這部分空間是沒有使用的。我們可以做個(gè)小實(shí)驗(yàn)，見下圖：

MySQL的Innodb_buffer_pool開了5G，但實(shí)際內(nèi)存只有3G。
講了這么多，現(xiàn)在言歸正傳，回到我們最早提到的RDS實(shí)例被OS Kill掉的問題上來，前面我們也提到了，一旦實(shí)例可用內(nèi)存不足，MySQL一般都會(huì)成為OOM_Killer的首選目標(biāo)。這里就涉及到兩個(gè)問題：

1.為什么會(huì)內(nèi)存不足？
2.如何讓MySQL擺脫被Kill的厄運(yùn)？
首先我們來看一下第一個(gè)問題。內(nèi)存不足這個(gè)問題產(chǎn)生原因很多，但是主要就兩個(gè)方面，第一個(gè)是MySQL自身內(nèi)存的規(guī)劃有問題。第二個(gè)就是一般部署MySQL的服務(wù)器，都會(huì)部署很多的監(jiān)控或者定時(shí)任務(wù)腳本，而這些腳本往往缺少必要的內(nèi)存限制，導(dǎo)致在高峰期的時(shí)候占用大量的內(nèi)存，導(dǎo)致觸發(fā)Linux OOM_Killer機(jī)制，MySQL就無辜犧牲了。
那如何才能讓MySQL擺脫被Kill的厄運(yùn)呢？ MySQL被Kill的根源在于Linux超售的內(nèi)存分配機(jī)制，前面也提到了，只要存在這種超售的機(jī)制，就不可能完全避免某一個(gè)應(yīng)用程序被Kill的風(fēng)險(xiǎn)。那要使得MySQL一定不會(huì)被Kill掉，只能禁止操作系統(tǒng)超出實(shí)際內(nèi)存空間的分配內(nèi)存。但是前面我們也提過，對(duì)于部署了MySQL的服務(wù)器，我們不建議這么做，因?yàn)镸ySQL的很多內(nèi)存都是剛開始申請(qǐng)了，并不是立即使用的，OS一旦禁止超售，這不僅對(duì)MySQL自身內(nèi)存規(guī)劃提出更苛刻的要求，同時(shí)也存在內(nèi)存無法充分利用的問題。同時(shí)，MySQL的每個(gè)連接的私有內(nèi)存是動(dòng)態(tài)分配的，如果分配不到，就會(huì)直接導(dǎo)致服務(wù)器Crash，這樣也會(huì)增加MySQL Crash的風(fēng)險(xiǎn)。
既然受限于操作系統(tǒng)，無法完全做到避免被Kill，那只能盡量降低MySQL被Kill的幾率。我覺得至少可以做下面3個(gè)事情：

1)合理的規(guī)劃MySQL的內(nèi)存使用。
2)調(diào)整OOM_adj參數(shù)，將MySQL被OOM_Killer鎖定的優(yōu)先級(jí)降低。
3)加強(qiáng)內(nèi)存的監(jiān)控和報(bào)警，一旦報(bào)警，DBA應(yīng)該迅速介入，Kill掉一些占用較多內(nèi)存的連接。

最新評(píng)論