worker_processes应设为CPU逻辑核心数或auto，过大导致上下文切换开销增加、惊群效应和内存浪费，过小则无法利用多核；需配合worker_cpu_affinity绑定核心、调高ulimit-n，并通过CPU利用率、QPS、上下文切换等指标验证效果。
worker_processes 本身不是性能指标，而是直接影响性能的关键配置参数。它的合理设置最终要通过几个可观测、可量化的指标来验证效果。
CPU 利用率是否均衡
这是最直接的衡量依据。理想状态下，各 CPU 核心负载应接近平均，没有明显单核打满而其他核心闲置的情况。
- 使用 top -H 或 htop 查看每个 nginx worker 进程的 CPU 绑定与占用分布
- 若启用 worker_cpu_affinity，可用 taskset -p <pid> 确认进程是否真正在指定核心上运行
- 持续高偏斜（如某核 95%，其余低于 30%）说明进程数过少或未绑定，或存在惊群/锁竞争
QPS 与连接吞吐变化
调整前后在相同压测条件下对比，能反映实际处理能力提升。
- 用 wrk 或 ab 对静态资源发起固定并发请求（如 1000 并发，持续 60 秒）
- 记录平均 QPS、延迟 P95/P99、失败率
- worker_processes 从 1 增至 auto 后，QPS 通常提升 2～5 倍（取决于原瓶颈是否在单核）；但超过逻辑核数后，QPS 可能持平甚至下降
上下文切换与调度开销
进程过多会显著增加内核调度压力，表现为非业务性 CPU 消耗上升。
- 监控 cs（context switch） 和 in（interrupts） 指标（vmstat 1）
- 正常负载下，每秒上下文切换数建议控制在 1 万以内；若超 3 万且伴随 QPS 下降，大概率是 worker 进程过多
- 配合 perf stat -e sched:sched_switch nginx 可进一步定位调度热点
错误日志与连接异常
不合理设置会引发底层资源争抢，留下明确痕迹。
- 检查 error.log 中是否有 "accept() failed (24: Too many open files)" —— 多因 ulimit 未同步调高，而非 worker_processes 本身问题
- 出现大量 "worker process … exited on signal 11" 或频繁重启，可能因内存不足（每个 worker 加载完整配置，进程数翻倍则内存占用近似翻倍）
- netstat 或 ss 输出中 TIME_WAIT 过多且 ESTABLISHED 占比偏低，说明连接处理链路阻塞，需结合 keepalive 和 upstream 超时排查，不单是 worker_processes 问题
