MySQL OOM 系列三 解脫MySQL被Kill的惡運。本站提示廣大學習愛好者：（MySQL OOM 系列三 解脫MySQL被Kill的惡運）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL OOM 系列三 解脫MySQL被Kill的惡運正文
後面兩章，我們剖析了Linux內存分派的戰略和Linux經由過程應用 OOM_Killer的機制處理了“超售”惹起的風險，MySQL同其他的運用法式一樣，在操作體系許可的規模內也是可以超售的，普通人懂得，Innodb_buffer_pool必需小於現實物理內存，不然MySQL會啟動掉敗。其實這是一個誤區，這個不是MySQL層掌握的，這個是操作體系（OS）層掌握的，就是後面提到的/proc/sys/overcommit_memory掌握OS能否許可“超售”。假如許可“超售”，則Innodb_buffer_pool可以遠遠跨越現實的內存空間年夜小，然則這部門空間是沒有應用的。我們可以做個小試驗，見下圖：
MySQL的Innodb_buffer_pool開了5G，但現實內存只要3G。
講了這麼多，如今言歸正傳，回到我們最早提到的RDS實例被OS Kill失落的成績下去，後面我們也提到了，一旦實例可用內存缺乏，MySQL普通都邑成為OOM_Killer的首選目的。這裡就觸及到兩個成績：
1.為何會內存缺乏？
2.若何讓MySQL解脫被Kill的惡運？
起首我們來看一下第一個成績。內存缺乏這個成績發生緣由許多，然則重要就兩個方面，第一個是MySQL本身內存的計劃有成績。第二個就是普通安排MySQL的辦事器，都邑安排許多的監控或許准時義務劇本，而這些劇本常常缺乏需要的內存限制，招致在岑嶺期的時刻占用年夜量的內存，招致觸發Linux OOM_Killer機制，MySQL就無辜就義了。
那若何能力讓MySQL解脫被Kill的惡運呢？ MySQL被Kill的本源在於Linux超售的內存分派機制，後面也提到了，只需存在這類超售的機制，就弗成能完整防止某一個運用法式被Kill的風險。那要使得MySQL必定不會被Kill失落，只能制止操作體系超越現實內存空間的分派內存。然則後面我們也提過，關於安排了MySQL的辦事器，我們不建議這麼做，由於MySQL的許多內存都是剛開端請求了，其實不是立刻應用的，OS一旦制止超售，這不只對MySQL本身內存計劃提出更刻薄的請求，同時也存在內存沒法充足應用的成績。同時，MySQL的每一個銜接的公有內存是靜態分派的，假如分派不到，就會直接招致辦事器Crash，如許也會增長MySQL Crash的風險。
既然受限於操作體系，沒法完整做到防止被Kill，那只能盡可能下降MySQL被Kill的概率。我認為至多可以做上面3個工作：
1)公道的計劃MySQL的內存應用。
2)調劑OOM_adj參數，將MySQL被OOM_Killer鎖定的優先級下降。
3)增強內存的監控和報警，一旦報警，DBA應當敏捷參與，Kill失落一些占用較多內存的銜接。
