我們受到非******，是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是更好的配置。
一如既往地，我們會爲客戶監控和管理這些類型問題，不斷升級默認安裝配置，並循環升級以影響系統。