歡迎光臨
每天分享高質量文章

一個小米SRE的日常工作

本文主要介紹了小米SRE的日常工作及遇到的各方面問題和處理方法,值得借鑒。
1、日常巡檢發現新擴容的一臺Web轉發服務器負載異常。比原來的稍高但仍然在正常範圍內,but作為一個SRE是不能放過任何異常。
2、安排好其他日常工作開始排查。
新增服務器系統版本跟原來不一致。(原來為CentOS 6.x,異常服務器為CentOS 7.x) ,異常服務器從LVS下線重裝,保證系統版本都為6.x依然沒有恢復。(論:保持環境統一重要性。)
為什麼要重新裝CentOS 6.x呢?當時懷疑線上Nginx是在CentOS 6.x環境下編譯的,運行在CentOS 7.x下麵,可能會是這個原因。
仔細對比下環境,確認系統中Nginx版本Nginx配置完全一樣。
3、通過火焰圖分析大部分CPU占用為https握手階段函式(bn_sqr8x_interna,mul4x_internall),查看log發現問題服務器及正常服務器https及http請求數量相同。(此路不通)

4、既然軟體環境一樣,來看硬體及驅動。通過監控確定新增一批服務負載都比原來的稍高,新增服務器及原來服務器CPU,記憶體硬碟配置一樣。確定新增服務器沒有,節能沒開,CPU記憶體頻率正常,硬碟讀寫正常,找系統同事查看未見硬體故障。部分驅動版本信息不同,進行了替換驗證,整個過程是痛苦的,感謝系統及dell的同學。(大家一個team一起背鍋)
5、通過找不同,沒有解決了問題。但是我們還是要繼續,現在我們很好奇很想知道答案。繼續分析,我們發現了問題,服務器CPU很不均衡。為什麼不均衡呢,strace一下發現大量的(Resourcetemporarilyunavailable)CPU在空轉。
來看下Nginx對請求分配的模型。Master行程監聽端口號(例如80),所有的nginx worker行程開始用epoll_wait來處理新事件(Linux下),如果不加任何保護,當一個新連接來臨時,會有多個worker行程在epoll_wait後被喚醒,然後只有一個執行緒處理這個請求,其他的則會失敗,CPU空轉負載升高。這就是所謂的epoll_wait驚群效應。當然Nginx會有辦法處理這個問題:加鎖。
6、剩下的就簡單了。對問題服務器手動配置上鎖(accept_mutex),然後負載正常了(每把鎖都是雙刃劍,加不加要具體問題具體分析)。但是,你可能會有疑問,版本是一樣的啊,正常的服務器也沒手動加鎖啊。偉大的福爾摩斯說過:“When you have eliminated the impossibles,whatever remains,however improbable,must be the truth.”真相就是線上Nginx根本不是一個版本(一臉懵逼)。手動查看,發現線上運行的Nginx檔案被刪除了,線上運行了一個不存在的版本,存在的版本是更新了的。原來正常的服務器上線是reload新版Nginx,不會生效,新增的服務器是start運行的新版Nginx。
7、下麵的問題就是tengine2.1跟tengine2.2accept_mutex引數由預設的on改為了off,為什麼要改呢?與時俱進,當初這個引數是為了避免在epoll_wait出現驚群效應,可以參考:https://www.jianshu.com/p/21c3e5b99f4a。新版內核已經有了處理這個的方法,不再需要Nginx單獨配置。
總結:反思並完善整個運維流程,以避免相關問題再次發生,對SRE來說永遠是最重要的。
一些啟示:
  1. 線上環境儘量完全一致(容器化可以很好的解決這一點);

  2. 每次變更都要謹慎及測試。

赞(0)

分享創造快樂