worker_processes过低会导致nginx无法利用多核cpu，请求在单个worker中串行排队，吞吐受限；需通过cpu利用率分布不均、活跃连接堆积、压测qps偏低且延迟抖动剧烈、vmstat中cs值异常等多维度交叉验证。
当 worker_processes 设置过低时，Nginx 无法充分利用多核 CPU，请求被迫在单个 worker 中串行排队，吞吐量会明显受限。定位这类瓶颈不能只看“CPU 使用率低”，而要结合多个维度交叉验证。
CPU 利用率分布严重不均
这是最直观的信号。使用 top -H 或 htop 观察所有 nginx worker 进程的 CPU 占用：
- 如果仅有一个 worker 进程持续占用接近 100% CPU，其余 worker（哪怕有多个）长期低于 5%，说明实际有效并发进程极少
- 即使
worker_processes 4，但ps aux | grep nginx显示只有 1 个 master + 1 个 worker 在运行，可能是配置未生效或启动失败 - 检查
nginx -t输出和 error.log，确认是否因语法错误导致部分 worker 未启动
活跃连接堆积在单一 worker 上
启用 http_stub_status_module 后访问 /nginx_status，重点关注 Active connections 和各 worker 的负载差异：
- Active connections 高，但 Reading/Writing/Waiting 比例异常——例如 Waiting 长期占 90% 以上，说明连接已建立但处理缓慢，可能卡在单 worker 的事件循环里
- 配合
ps -eo pid,comm,pcpu,pmem --sort=-pcpu | grep nginx查看每个 worker 进程的实际 CPU 占用，确认是否集中在某一个 PID - 若使用
worker_cpu_affinity，用taskset -p <pid></pid>验证该 worker 是否真的绑定了某个核心；若未绑定，也可能表现为“看似多进程，实则争抢同一核”
压测中 QPS 上不去且延迟抖动剧烈
在相同并发压力下，对比不同 worker_processes 值的表现：
- 用
wrk -t4 -c1000 -d60s http://host/对静态资源压测，记录 QPS 和 P95 延迟 -
worker_processes 1时 QPS 稳定在 8k、P95=120ms；改为4后 QPS 跃升至 28k、P95 降至 35ms → 明确指向 worker 数不足 - 延迟曲线出现明显毛刺或长尾（如 1% 请求耗时超 1s），是单点处理能力饱和的典型特征
系统级指标暴露资源争抢痕迹
低 worker 数虽不直接引发高上下文切换，但会放大其他瓶颈的副作用：
- 用
vmstat 1观察cs（上下文切换）数值：若整体偏低（ -
netstat -ant | grep :80 | wc -l结果远高于worker_connections × worker_processes，说明连接在队列中堆积，新连接被内核丢弃 - error.log 中频繁出现
accept() failed (24: Too many open files)，不是因为 ulimit 小，而是因为单 worker 处理不过来，连接积压触发了文件描述符瞬时尖峰
