验证Nginx多进程在分布式压测下的稳定性，需从进程级CPU均衡、连接生命周期管理、系统层瓶颈交叉验证及wrk分阶段压测四方面穿透分析，识别隐性失衡与调度退化。
测试 Nginx 多进程架构在分布式压测下的稳定性，核心是验证多个 worker 进程能否在高并发、跨节点流量冲击下保持负载均衡、资源可控、连接可靠。不能只看总 QPS 是否达标，而要穿透到进程级、CPU 级、连接级指标，识别隐性失衡与调度退化。
关注进程级负载是否均匀
多进程稳定性的第一道防线是各 worker 是否“齐心协力”。分布式压测中若某几个 worker CPU 持续高于 90%，其余长期低于 30%，说明连接分发已失衡：
- 用 top -p $(pgrep nginx | head -n 8 | xargs) 实时观察前 8 个 worker 的 CPU 占用（适配 8 核机器），重点关注方差：标准差超过 25% 即需排查
- 检查 accept_mutex on; 是否启用（默认开启），它可防止“惊群”；若关闭后出现大量 accept() failed (24: Too many open files)，说明无锁竞争导致连接争抢
- 确认 worker_cpu_affinity auto; 已生效：执行 ps axo pid,cmd,psr | grep nginx，查看每个 worker 的 psr 列是否分散且不重复
监控连接生命周期与异常堆积
分布式压测常伴随短连接激增或长连接复用异常，易暴露多进程在连接管理上的脆弱点：
- 通过 ss -s 或 netstat -s | grep -i "active\|passive" 统计全系统连接状态，重点关注 active connections 和 TIME_WAIT 数量比：若后者持续超前者 3 倍，说明连接回收滞后，需调优 net.ipv4.tcp_tw_reuse = 1
- 启用 stub_status 模块，在压测中轮询 /nginx_status，提取 Active connections 及各 upstream 的 Active 值，对比不同时间点波动幅度（>15% 视为抖动异常）
- 检查 error.log 中是否高频出现 upstream timed out 或 no live upstreams：前者反映后端响应慢阻塞 worker，后者可能因健康检查误判导致部分进程失去可用节点
结合系统层指标交叉验证瓶颈归属
多进程表现异常，未必是 Nginx 自身问题，需联动操作系统指标定位根因：
- 用 vmstat 1 观察 si（软中断）列：若某 CPU 的 si 长期 >80%，说明网卡中断处理过载，此时 worker 进程再均衡也无济于事，应启用 reuseport 或调整 RPS
- 运行 sar -n DEV 1 查看网卡 rxkB/s 和 txkB/s：接近千兆网卡理论值（~125 MB/s）即为带宽瓶颈，此时增加 worker 数只会加剧排队
- 检查 ulimit -n 与 worker_rlimit_nofile 是否匹配：例如设了 8 个 worker、worker_connections 65535，系统 ulimit 至少需设为 60 万，否则会静默丢弃连接
用 wrk 分阶段施压并捕获拐点行为
分布式压测不是堆并发，而是找“临界稳态”。推荐使用 wrk 搭配脚本自动化采集关键窗口数据：
- 第一阶段（稳态基线）：wrk -t8 -c2000 -d120s --latency http://nginx-ip/，记录 P95 延迟和各 worker CPU 平均值
- 第二阶段（压力爬坡）：每 30 秒提升 1000 并发，直到 P95 延迟跳升 >40% 或错误率突破 0.5%，立即暂停并抓取该时刻的 ss -s、top、nginx_status
- 第三阶段（稳态维持）：在拐点并发下持续压测 5 分钟，每 10 秒采集一次 Active connections 和 Reading/Writing/Waiting 三态分布，若 Waiting 比例持续 >60%，说明事件循环已饱和
