緣起

近期排查了一個問題，epoll驚群的問題，起初我并不認為這是驚群導致，因為從現(xiàn)象上看，只是體現(xiàn)了CPU不均衡。一共fork了20個Server進程，在請求負載中等的時候，有三四個Server進程呈現(xiàn)出比較高的CPU利用率，其余的Server進程的CPU利用率都是非常低。

中斷，軟中斷都是均衡的，網(wǎng)卡RSS和CPU之間進行了bind之后依然如故，既然系統(tǒng)層面查不出個所以然，只能從服務的角度來查了。

自上而下的排查首先就想到了strace，沒想到一下子就暴露了原形：

accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
如果僅僅strace accept，即加上“-e trace=accept”參數(shù)的話，偶爾會有accept成功的現(xiàn)象：

accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?{sa_family=AF_INET,?sin_port=htons(39306),?sin_addr=inet_addr("172.16.1.202")},?[16])?=?19
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
accept(4,?0x9ecd930,?[16])??????????????=?-1?EAGAIN?(Resource?temporarily?unavailable)
大量的CPU空轉(zhuǎn)，進一步加大請求負載，CPU空轉(zhuǎn)明顯降低，這說明在預期的空轉(zhuǎn)期間，新來的請求降低了空轉(zhuǎn)率…現(xiàn)象明顯偏向于這就是驚群導致的之判斷！

本文將詳細說一下關(guān)于epoll的細節(jié)?，F(xiàn)在開始！

題目中為什么是“再談”，因為這個話題別人已經(jīng)聊過很多了，我順勢繼續(xù)下去而已。

簡單介紹驚群和事件模型

關(guān)于什么是驚群，這里不再做概念上的解釋，能搜到這篇文章的想必已經(jīng)有所了解，如果仍有概念上的疑惑，自行百度或者谷歌。

驚群問題一般出現(xiàn)在那些web服務器上，曾經(jīng)Linux系統(tǒng)有個經(jīng)典的accept驚群問題困擾了大家非常久的時間，這個問題現(xiàn)在已經(jīng)在內(nèi)核曾經(jīng)得以解決，具體來講就是當有新的連接進入到accept隊列的時候，內(nèi)核喚醒且僅喚醒一個進程來處理，這是通過以下的代碼來實現(xiàn)的：

list_for_each_entry_safe(curr,?next,?