安排好其他日常工作開始排查。

• 新增服務器系統版本跟原來不一致。（原來為centos6.x，異常服務器為centos7.x） ，異常服務器從lvs下線重裝，保證系統版本都為6.x依然沒有恢復。（論：保持環境統一重要性。）為什么要重新裝centos6.x呢？當時懷疑線上nginx是在centos6.x環境下編譯的，運行在centos7.x下面，可能會是這個原因。

• 仔細對比下環境，確認系統版本nginx版本nginx配置完全一樣。

通過找不同沒有解決問題了。但是我們還是要繼續，現在我們很好奇很想知道答案。繼續分析我們發現了問題服務器cpu很不均衡。為什么不均衡了，strace一下發現大量的(Resourcetemporarilyunavailable)cpu在空轉。

來看下nginx對請求分配的模型。master進程監聽端口號（例如80），所有的nginx worker進程開始用epoll_wait來處理新事件（linux下），如果不加任何保護，一個新連接來臨時，會有多個worker進程在epoll_wait后被喚醒然后只有一個線程處理這個請求其他的則會失敗。cpu空轉負載升高。這就是所謂epoll_wait驚群效應。當然nginx會有辦法處理這個問題：加鎖。