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

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

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

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

最新評論