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

標籤：雲端運算   伺服器   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是更好的配置。

一如既往地，我們會為客戶監控和管理這些類型問題，不斷升級預設安裝配置，並迴圈升級以影響系統。

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