worker_processes直接决定Nginx启动的独立工作进程数，是并发处理能力的“骨架”；应设为CPU物理核心数或auto（自动识别），不可超过核心数以防调度开销、惊群效应和内存浪费，需配合worker_cpu_affinity、worker_rlimit_nofile等参数协同调优。
worker_processes 直接决定 Nginx 能启动多少个独立工作进程，它是并发处理能力的“骨架”。设少了，CPU 空转、请求排队；设多了，进程抢资源、上下文切换拖慢整体响应。最稳妥的起点是等于服务器 CPU 物理核心数，或直接用 auto 让 Nginx 自动识别。
worker_processes 的取值逻辑
这个指令只能写在 main 块（配置文件最外层），支持三种写法：
-
数字：如
worker_processes 4;—— 固定启动 4 个进程，适合核数明确且稳定的环境 -
auto：Nginx 启动时读取
/proc/cpuinfo获取物理核心数，推荐用于大多数生产环境 - off：仅 Windows 支持，Linux/Unix 下无效
为什么通常不建议超过 CPU 核心数
Nginx 是事件驱动模型，单个 worker 已能高效处理数千连接。盲目加进程反而带来三重开销：
- CPU 时间片被频繁切分，大量时间花在进程调度而非处理请求
- 多个 worker 共享监听端口时，仍存在轻微“惊群”效应（即使 1.9.1+ 启用了 accept_mutex）
- 每个 worker 都要加载完整配置、缓存结构、连接上下文，内存占用线性上升
实测显示：8 核机器设为 16 个 worker，在高并发短连接场景下，QPS 反而比设为 8 下降 5%～15%。
特殊场景下的合理调整
auto 是默认推荐，但以下情况需手动干预：
-
容器化部署：Kubernetes 中若限制了 CPU limit（如
resources.limits.cpu: "2"），必须显式设为worker_processes 2;，否则 auto 会读到宿主机核数 -
混合负载服务器：Nginx 与 MySQL、Java 应用共存时，可预留 1～2 核，设为
worker_processes $(nproc --all)-2;（需配合启动脚本） - 上游响应极慢：大量反向代理请求卡在等待后端响应上，可略增 worker（如核数 ×1.2），但优先应优化 upstream 的 timeout 和 retry 策略
必须同步检查的配套参数
worker_processes 不是孤立参数，需和这些设置协同生效：
-
worker_cpu_affinity：绑定每个 worker 到指定 CPU 核（如
0001 0010 0100 1000），减少跨核缓存失效 -
worker_rlimit_nofile：提升单个 worker 可打开文件数上限，至少不低于
worker_connections - events { worker_connections }：它和 worker_processes 共同决定理论最大连接数 = 两者乘积
修改后务必执行 nginx -t 检查语法，并用 nginx -s reload 平滑生效。
