~~~ 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; } ~~~