我們受到非黑客攻擊,是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
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章
通過緩存中的複製延遲標記實現對PHP/MySQL的讀/寫的分離式控制
ChinaNetCloud
2020-06-29 18:40:35
成長型公司的存儲架構
ChinaNetCloud
2020-06-29 18:40:32
我們經常遇見的問題
ChinaNetCloud
2020-02-21 01:47:16
MySQL – 不要爲運行應用程序的用戶分配DBA權限
ChinaNetCloud
2020-02-21 01:47:03
Redis 與 Memcache
ChinaNetCloud
2020-02-21 01:47:03
打開文件數限制功能不斷地製造問題
ChinaNetCloud
2020-02-21 01:47:03
雲服務器成本與物理服務器
ChinaNetCloud
2018-09-02 03:55:48
爲什麼需要使用及如何使用CDN(更新)
ChinaNetCloud
2018-09-02 03:55:46
雲絡結合Docker和OpsWorks,在AWS平臺發佈了全自動DevOps系統
ChinaNetCloud
2018-09-02 03:55:46
深層設計
ChinaNetCloud
2018-09-02 03:55:46
Linux TCP 回收與重用
ChinaNetCloud
2018-09-02 03:55:46
OaaS-運維即服務 簡介
ChinaNetCloud
2018-09-02 03:55:46
經常運行YSlow可使您獲得最好的網站性能
ChinaNetCloud
2018-09-02 03:55:45
中國72%的個人電腦仍然使用Windows XP- SSL/SNI 問題
ChinaNetCloud
2018-09-02 03:55:41