worker_processes并非越多越好，需结合cpu架构、内存拓扑、并发模型和资源限制综合调优；常规单路服务器设为物理核心数较优，numa架构下须按节点均分并绑定cpu与内存亲和，且须协同调整worker_connections、worker_rlimit_nofile和cpu亲和性参数。
worker_processes 不是越多越好，也不是简单设成 CPU 核心数就万事大吉。真正的性能平衡点，取决于 CPU 架构、内存拓扑、并发模型和系统资源限制四者的实际匹配程度。
CPU 核心数只是起点，不是终点
在常规单路服务器上，worker_processes 设为 auto 或显式等于物理核心数（如 8 核设为 8），通常能获得较好吞吐。但要注意：
- 超线程（HT）开启时，逻辑核数翻倍，但 worker_processes 不宜直接设为逻辑核总数——多数场景下物理核数更稳，避免上下文切换开销上升
- 设为 1 会浪费多核能力；设为远高于核心数（比如 32 核机器设 64），反而因进程调度争抢、锁竞争和缓存失效导致 QPS 下降
- 可通过
ab或wrk压测不同值（如 4/8/12/16），观察 CPU 利用率与请求延迟拐点，找到响应延迟开始抬升前的最优值
NUMA 架构下必须按节点拆分
双路或多路服务器若忽略 NUMA 拓扑，直接设 worker_processes auto（比如识别出 64 个逻辑核就启 64 个进程），极易引发跨节点内存访问，延迟跳升 30% 以上。
- 先运行
numactl --hardware查清节点分布，例如：Node 0（CPU 0–31，内存 128GB）、Node 1（CPU 32–63，内存 128GB） - worker_processes 应设为每节点分配相同数量，如总共 32 个（每节点 16 个），而非 64 个
- 配合
worker_cpu_affinity绑定各组 Worker 到对应节点 CPU，并用numactl启动 Nginx 强制内存亲和，确保numastat -p PID显示本地节点内存占比 >95%
配套参数必须协同调整
worker_processes 单独调优无效，必须与以下三项联动校准：
- worker_connections：乘积（processes × connections）决定理论并发上限，但单 Worker 连接数过高（如 >65536）会导致内存占用陡增（每个连接约 240 字节），建议控制在 16384–32768 区间
-
worker_rlimit_nofile：需 ≥ worker_connections × worker_processes，同时系统级
fs.file-max和用户 limits（/etc/security/limits.conf）也要同步提升至 10 万以上 -
CPU 亲和性：启用
worker_cpu_affinity auto可自动绑定，但在 NUMA 场景下推荐手动指定掩码或结合 numactl 控制，避免 Worker 跨节点调度
验证是否真达到平衡点
别只看配置文件和 ps 进程数。真正有效的验证方式有三个：
- 用
htop或pidstat -u 1观察各 Worker CPU 占用是否均衡，是否存在个别进程长期空转或打满 - 压测时监控
nginx_stub_status的 Active connections + Waiting connections 比例，Waiting 长期 >10% 说明进程数或连接数已成瓶颈 - 查
/proc/PID/status中的Threads和voluntary_ctxt_switches，频繁自愿上下文切换往往意味着进程数过多或锁争用严重
