worker_connections与accept_mutex深度耦合：前者限定单worker连接上限，后者调控多worker间连接争抢；设值不当会引发伪惊群、建连失败或cpu空转。
worker_connections 和 accept_mutex 表面看是两个独立配置，实际在连接接纳阶段深度耦合：前者定义单个 worker 的连接容量上限，后者决定这些连接如何被多个 worker 安全、高效地争抢获取。二者配合失当，轻则浪费资源，重则触发伪惊群、建连失败或 CPU 空转。
worker_connections 直接影响 accept_mutex 的“开关逻辑”
accept_mutex 并非简单开/关的锁开关，它的启用状态会动态受当前连接负载调节。Nginx 内部通过以下公式计算是否临时禁用该锁：
- ngx_accept_disabled = worker_connections / 8 − 当前空闲连接数
- 当结果大于 0，表示该 worker 已接近饱和（空闲连接不足总量的 1/8），它会主动退出 accept 竞争，把新连接机会让给其他较空闲的 worker
- 这意味着：worker_connections 设得过小（如 512），即使并发不高，也容易触发频繁的“自退让”，导致部分 worker 长期闲置、其余 worker 过载
accept_mutex 开启时，worker_connections 才真正“可调度”
若 accept_mutex 关闭（不推荐），所有 worker 同时监听同一 listen socket，在 epoll_wait 返回后都会尝试 accept —— 大量进程争抢同一个内核队列，多数失败并重试，造成无效唤醒。此时：
- worker_connections 值再大也无意义：连接还没真正建立，就卡在竞争环节
- 系统表现为高 sy%（内核态 CPU）、大量短时上下文切换、netstat 中 listen overflows 上升
- 只有 accept_mutex on 时，Nginx 才能确保任一时刻仅一个 worker 执行 accept，让 worker_connections 的设定值真正反映其有效承载能力
二者协同决定连接接纳吞吐与稳定性
真实建连效率不仅取决于单 worker 能 hold 多少连接，更取决于“新连接进来时，能否快速、无冲突地落到某个有余量的 worker 上”。这需要两层配合：
- 底层分发：靠 SO_REUSEPORT（内核级）或 accept_mutex（Nginx 级）避免多进程争抢；前者更优，但需 Linux ≥3.9 且显式开启
- 上层承接：每个 worker 必须留足空闲 connection slot（即 worker_connections − 当前活跃连接数），否则即便分发到位，也会因无资源而丢弃
- 例如：4 个 worker，worker_connections=4096，总并发达 15000 时，若未启用 SO_REUSEPORT 或 accept_mutex，很可能 3 个 worker 已满，只剩 1 个在忙于 accept，其余连接在内核队列排队甚至溢出
配置建议：匹配业务连接特征来设值
不要套用固定数值，而是结合连接生命周期判断：
- 短连接 API（如 HTTP JSON 接口）：连接秒级建立+关闭，worker_connections 可设为 8192–16384，accept_mutex 必须 on，multi_accept on 加速吸走 burst 流量
- 长连接透传（如 stream 模块代理 DB/MQTT）：连接持续数分钟至小时，连接数稳定但总量大，worker_connections 可设更高（32768+），但必须同步调大 ulimit 和 worker_rlimit_nofile，accept_mutex 仍建议保持 on
- 混合场景：优先按峰值连接数 × 1.2 设定 worker_connections，并确保 accept_mutex on + multi_accept on 组合启用
