压测和调优worker_connections不是追求最大值，而是确保其与秒杀短连接爆发特征、系统资源（file-max/ulimit/worker_rlimit_nofile）严丝合缝，避免静默拒绝或资源耗尽；需在70%～80%负载时验证延迟、qps、accept失败及cpu软中断等稳定性指标。
压测和调优 worker_connections 不是为了凑出一个“最大数字”，而是确保它在秒杀流量下不成为连接入口的硬瓶颈——既不因设太低而静默拒绝连接，也不因设太高导致系统资源耗尽或上下文切换失控。关键在于让配置值与真实业务连接行为、系统资源能力严丝合缝。
明确秒杀场景的连接特征
秒杀活动通常表现为短连接密集爆发：大量用户在整点瞬间发起 HTTP/1.1 请求（如抢购接口），连接建立快、处理快、关闭快。这种模式下：
- 每个请求几乎对应一个新 TCP 连接，
ESTAB数会快速冲高，TIME_WAIT也会密集堆积； - fd 消耗压力远高于长连接场景，因为连接生命周期短、新建频率高；
- 实际并发连接数 ≈ QPS × 平均响应时间（例如 2 万 QPS × 50ms = 1000 并发连接），但峰值瞬时连接数可能达其 3–5 倍，需预留缓冲。
三层文件描述符限制必须对齐
缺一不可，否则压测结果完全失真。三者取最小值，才是真实上限：
-
系统级：
/proc/sys/fs/file-max≥worker_processes × worker_connections × 1.3（留出日志、SSL 缓存、TIME_WAIT 等开销）； -
用户级：运行 Nginx 的用户（如
www-data或nginx）的ulimit -n≥worker_processes × worker_connections；在/etc/security/limits.conf中设置：
nginx soft nofile 65536
nginx hard nofile 65536 -
Nginx 级：主配置块中声明
worker_rlimit_nofile 65536;（建议 ≥worker_connections，推荐设为相同值或 1.2 倍）；
生效后用 cat /proc/$(pgrep nginx)/limits | grep "Max open files" 验证是否真正加载。
压测目标不是“跑满”，而是验证稳定性边界
使用 wrk 或 JMeter 模拟秒杀流量（如 3 秒内突增 2 万连接），重点观察：
- 当活跃连接数达到配置值的 70%～80% 时，延迟是否开始明显上升、QPS 是否平台化或下降；
- 是否出现
accept() failed (24: Too many open files)或客户端报Connection reset； -
ss -s输出中estab是否线性增长、无断崖式回落； - CPU %us 是否持续高于 70%，或出现频繁的软中断（
si%）飙升——这提示网络栈或 epoll 事件处理过载。
结合进程模型与事件参数协同调优
单改 worker_connections 效果有限，必须配套调整：
-
worker_processes auto;（自动匹配 CPU 核数），避免进程过多引发调度抖动； -
worker_cpu_affinity auto;（Linux 4.0+ 支持），减少缓存失效； -
use epoll;（显式指定，防止回退到 select/poll）； -
multi_accept on;，让单次事件循环尽可能多 accept 新连接，缓解突发排队； -
keepalive_timeout 15;，避免长连接空占槽位（秒杀场景一般不依赖 keepalive）； - 关闭未启用的 access_log 写入，或启用
buffer=64k flush=5s减少 fd 占用。
对于 4–8 核机器，典型秒杀配置可设 worker_connections 16384，配合 worker_processes 4 和足额文件描述符限制，即可稳定支撑 5 万+ 瞬时连接。
