來自Killer內(nèi)核配置改變的威脅–Swappiness

我們受到非******，是Linux內(nèi)核版本3.5-rc1以及RedHat backport補(bǔ)丁應(yīng)對swappiness=0。這是一種真實(shí)的威脅，我們一名客戶受到影響，被利用OOM機(jī)制使得MySQL主數(shù)據(jù)庫服務(wù)器崩潰。這個(gè)對內(nèi)核的“微小”改變導(dǎo)致系統(tǒng)不能適當(dāng)進(jìn)行Swap，直接導(dǎo)致OOM機(jī)制殺掉MySQL進(jìn)程。這就對如下解釋產(chǎn)生懷疑：系統(tǒng)已擁有128GB內(nèi)存，很多內(nèi)存處于空閑狀態(tài)，同時(shí)擁有128GB的空閑虛擬內(nèi)存，所以在任何情況下都不該啟動(dòng)OOM機(jī)制。

我們本以為原因是NUMA（以前寫過關(guān)于NUMA的文章），但是如果是這樣的話，由于intra-node 我們就會看到一些過度的Swapping。我們通過安裝numctl，配置mysql-safe，以便使用NUMA交互 模式，但是最終還是崩潰。

原來，該服務(wù)器擁有一個(gè)RHEL/Centos 6.4的新內(nèi)核2.6.32-358，發(fā)布于2013年2月。此版本內(nèi)核及以后版本均擁有backport補(bǔ)丁，系統(tǒng)可升級到6.4以及更高，我們期望在這一關(guān)鍵領(lǐng)域能出現(xiàn)很多問題。

這很令人沮喪，因?yàn)镽edHat本不該去改變backport中或像RHEL6的一個(gè)生命周期中的一些行為，他們的目的很明確，像這樣的事情不會發(fā)生，例如在系統(tǒng)5-10年生命中行為是一致的。因此當(dāng)在一個(gè)產(chǎn)品生命周期中像這樣的一個(gè)主要問題出現(xiàn)時(shí)，情況就很糟，諸如強(qiáng)制升級、配置改變、默認(rèn)安裝升級、監(jiān)控以及審計(jì)改變等。大部分最新的Debian/Ubuntu 系統(tǒng)也將會有這些問題，因?yàn)樗麄円灿懈聝?nèi)核，也許同樣的backport.  

關(guān)于swappiness，通常被工程師們所誤解。它可以設(shè)置為從0-100的值，以通知內(nèi)核哪個(gè)更重要，是pagecache(file cache)還是application memory。默認(rèn)值為60，表示可以較多使用pagecache內(nèi)存，但是這個(gè)對服務(wù)器是一個(gè)非常錯(cuò)誤的配置。從虛擬化的角度來說，所有的服務(wù)器均需要application memory，更甚于file cache，因此我們一直設(shè)置為0，表示在swap任何application memory 之前會一直釋放 file cache。但是現(xiàn)在，這個(gè)bug導(dǎo)致更少的swapping，以致大幅增加在內(nèi)存壓力下OOM機(jī)制起作用的機(jī)會，這個(gè)問題確實(shí)不是我們所想要的。 能夠快速解決的技術(shù)方案又是怎樣的？幸運(yùn)的是，我們有很簡單的方案。設(shè)置swappiness為1，這和0幾乎是相同的優(yōu)先權(quán)，以保護(hù)application memory，但是不會觸發(fā)內(nèi)核的改變。如此說來，1比0是更好的配置。

一如既往地，我們會為客戶監(jiān)控和管理這些類型問題，不斷升級默認(rèn)安裝配置，并循環(huán)升級以影響系統(tǒng)。