本文主要介紹了小米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來說永遠是最重要的。一些啟示：
知識星球
