來自Killer內核配置改變的威脅–Swappiness

咱們受到非******，是Linux內核版本3.5-rc1以及RedHat backport補丁應對swappiness=0。這是一種真實的威脅，咱們一名客戶受到影響，被利用OOM機制使得MySQL主數據庫服務器崩潰。這個對內核的「微小」改變致使系統不能適當進行Swap，直接致使OOM機制殺掉MySQL進程。這就對以下解釋產生懷疑：系統已擁有128GB內存，不少內存處於空閒狀態，同時擁有128GB的空閒虛擬內存，因此在任何狀況下都不應啓動OOM機制。

咱們本覺得緣由是NUMA（之前寫過關於NUMA的文章），可是若是是這樣的話，因爲intra-node 咱們就會看到一些過分的Swapping。咱們經過安裝numctl，配置mysql-safe，以便使用NUMA交互 模式，可是最終仍是崩潰。

原來，該服務器擁有一個RHEL/Centos 6.4的新內核2.6.32-358，發佈於2013年2月。此版本內核及之後版本均擁有backport補丁，系統可升級到6.4以及更高，咱們指望在這一關鍵領域能出現不少問題。

這很使人沮喪，由於RedHat本不應去改變backport中或像RHEL6的一個生命週期中的一些行爲，他們的目的很明確，像這樣的事情不會發生，例如在系統5-10年生命中行爲是一致的。所以當在一個產品生命週期中像這樣的一個主要問題出現時，狀況就很糟，諸如強制升級、配置改變、默認安裝升級、監控以及審計改變等。大部分最新的Debian/Ubuntu 系統也將會有這些問題，由於他們也有更新內核，也許一樣的backport.  

關於swappiness，一般被工程師們所誤解。它能夠設置爲從0-100的值，以通知內核哪一個更重要，是pagecache(file cache)仍是application memory。默認值爲60，表示能夠較多使用pagecache內存，可是這個對服務器是一個很是錯誤的配置。從虛擬化的角度來講，全部的服務器均須要application memory，更甚於file cache，所以咱們一直設置爲0，表示在swap任何application memory 以前會一直釋放 file cache。可是如今，這個bug致使更少的swapping，以至大幅增長在內存壓力下OOM機制起做用的機會，這個問題確實不是咱們所想要的。 可以快速解決的技術方案又是怎樣的？幸運的是，咱們有很簡單的方案。設置swappiness爲1，這和0幾乎是相同的優先權，以保護application memory，可是不會觸發內核的改變。如此說來，1比0是更好的配置。

一如既往地，咱們會爲客戶監控和管理這些類型問題，不斷升級默認安裝配置，並循環升級以影響系統。