轉：Nginx的accept_mutex配置

一般多數人不會注意Nginx的accept_mutex配置，不過實際上它對系統的吞吐量有必定的影響。

 

events {
accept_mutex off;
}

 

 

讓咱們看看accept_mutex的意義：當一個新鏈接到達時，若是激活了accept_mutex，那麼多個Worker將以串行方式來處理，其中有一個Worker會被喚醒，其餘的Worker繼續保持休眠狀態；若是沒有激活accept_mutex，那麼全部的Worker都會被喚醒，不過只有一個Worker能獲取新鏈接，其它的Worker會從新進入休眠狀態，這就是「驚羣問題」。

Nginx缺省激活了accept_mutex，也就是說不會有驚羣問題，但真的有那麼嚴重麼？實際上Nginx做者Igor Sysoev曾經給過相關的解釋：

OS may wake all processes waiting on accept() and select(), this is called thundering herd problem. This is a problem if you have a lot of workers as in Apache (hundreds and more), but this insensible if you have just several workers as nginx usually has. Therefore turning accept_mutex off is as scheduling incoming connection by OS via select/kqueue/epoll/etc (but not accept()).

簡單點說：Apache動輒就會啓動成百上千的進程，若是發生驚羣問題的話，影響相對較大；可是對Nginx而言，通常來講，worker_processes會設置成CPU個數，因此最多也就幾十個，即使發生驚羣問題的話，影響相對也較小。

另：高版本的Linux中，accept不存在驚羣問題，不過epoll_wait等操做還有。

…

假設你養了一百隻小雞，如今你有一粒糧食，那麼有兩種餵食方法：

• 你把這粒糧食直接扔到小雞中間，一百隻小雞一塊兒上來搶，最終只有一隻小雞能得手，其它九十九隻小雞隻能鎩羽而歸。這就至關於關閉了accept_mutex。
• 你主動抓一隻小雞過來，把這粒糧食塞到它嘴裏，其它九十九隻小雞對此渾然不知，該睡覺睡覺。這就至關於激活了accept_mutex。

能夠看到此場景下，激活accept_mutex相對更好一些，讓咱們修改一下問題的場景，我再也不只有一粒糧食，而是一盆糧食，怎麼辦？

此時若是仍然採用主動抓小雞過來塞糧食的作法就過低效了，一盆糧食不知何年何月才能喂完，你們能夠設想一下幾十只小雞排隊等着餵食時那種翹首以盼的情景。此時更好的方法是把這盆糧食直接撒到小雞中間，讓它們本身去搶，雖然這可能會形成必定程度的混亂，可是總體的效率無疑大大加強了。

…

Nginx缺省激活了accept_mutex，是一種保守的選擇。若是關閉了它，可能會引發必定程度的驚羣問題，表現爲上下文切換增多（sar -w）或者負載上升，可是若是你的網站訪問量比較大，爲了系統的吞吐量，我仍是建議你們關閉它。