~~~ events { #設置網路連接序列化，防止驚群現象發生，默認為on 驚群解釋當設置為off時，一個請求從客戶端過來，會導致nginx喚醒所有的進程，但只有一個會work進程能夠獲取到這個鏈接，其他空閑的work進程重新進入休眠（其他喚醒的空閑的work是無用功） #Apache動輒就會啟動成百上千的進程，如果發生驚群問題的話，影響相對較大；但是對Nginx而言，一般來說，worker_processes會設置成CPU個數，所以最多也就幾十個，即便發生驚群問題的話，影響相對也較小。 #另：高版本的Linux中，accept不存在驚群問題，不過epoll_wait等操作還有 比喻： /* 假設你養了一百只小雞，現在你有一粒糧食，那么有兩種喂食方法： 你把這粒糧食直接扔到小雞中間，一百只小雞一起上來搶，最終只有一只小雞能得手，其它九十九只小雞只能鎩羽而歸。這就相當于關閉了accept_mutex。 你主動抓一只小雞過來，把這粒糧食塞到它嘴里，其它九十九只小雞對此渾然不知，該睡覺睡覺。這就相當于激活了accept_mutex。 可以看到此場景下，激活accept_mutex相對更好一些，讓我們修改一下問題的場景，我不再只有一粒糧食，而是一盆糧食，怎么辦？ 此時如果仍然采用主動抓小雞過來塞糧食的做法就太低效了，一盆糧食不知何年何月才能喂完，大家可以設想一下幾十只小雞排隊等著喂食時那種翹首以盼的情景。此時更好的方法是把這盆糧食直接撒到小雞中間，讓它們自己去搶，雖然這可能會造成一定程度的混亂，但是整體的效率無疑大大增強了。 */ #高并發訪問量大的網站請設置為off(不要輕易用哦CPU占用會大幅提高，QPS嚴重惡化accept_mutex on時，QPS：3500，負載只有0.3 accept_mutex off時，QPS：2500，負載達到9.5，且CPU占用極高) accept_mutex on; #設置一個進程是否同時接受多個網絡連接，默認為off (on時告訴nginx收到一個新連接通知后接受盡可能多的連接) multi_accept on; #如果一個進程沒有互斥鎖，它將至少在這個值的時間后被回收，默認是500ms accept_mutex_delay 500; #指定只記錄由某個客戶端IP產生的debug信息 debug_connection 192.168.0.1; ############ # devpoll_changes # devpoll_events # kqueue_events # epoll_events ############ ########################## # rtsig_signo # rtsig_overflow_events # rtsig_overflow_test # rtsig_overflow_threshold ########################## #事件驅動模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport use epoll; #單個work進程允許的最大連接數，默認為512 worker_connections 1024; } ~~~