通常多数人不会注意Nginx的accept_mutex配置，不过实际上它对系统的吞吐量有一定的影响，今天生物钟紊乱睡不着觉，索性闲扯一下Nginx的accept_mutex配置。
让我们看看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）或者负载上升，但是如果你的网站访问量比较大，为了系统的吞吐量，我还是建议大家关闭它。
…
本文只是通过意淫来推断 accept_mutex 对性能的影响，实际上我们可以通过工具来测量 accept_mutex 对性能的影响，比如说 ngx-req-distr：
开启 accept_mutex 时：
shell> ./ngx-req-distr -m `cat /path/to/nginx.pid`
Tracing 12970 12971 12972 12974 (/path/to/nginx)...
Hit Ctrl-C to end.
^C
worker 12970: 0 reqs
worker 12971: 37 reqs
worker 12972: 127 reqs
worker 12974: 3 reqs
关闭 accept_mutex 时：
shell> ./ngx-req-distr -m `cat /path/to/nginx.pid`
Tracing 20433 20434 20435 20436 (/path/to/nginx)...
Hit Ctrl-C to end.
^C
worker 20433: 75 reqs
worker 20434: 32 reqs
worker 20435: 29 reqs
worker 20436: 44 reqs
明显可以看出，同开启 accept_mutex 相比，关闭 accept_mutex 的时候，请求在多个 worker 间的分配更均衡了，和我们意淫的结论基本一致。
