最佳值为 auto 或 4～8：优先用 worker_processes auto;，现代 nginx 自动识别物理核心数，避免超线程干扰；i/o 密集型静态服务通常 4～8 即达性能拐点，容器/云环境需按分配 vcpu 数显式设置，并同步配置 worker_rlimit_nofile、worker_connections 和 worker_cpu_affinity。
在高并发静态资源服务器上，worker_processes 的最佳实践值不是固定数字，而是要匹配物理 CPU 核心数，并结合 I/O 密集型特性做合理收敛——通常设为 auto 或 4～8 之间，而非盲目堆高。
优先用 worker_processes auto;
现代 Nginx（1.3.8+）支持自动识别物理核心数，写成 worker_processes auto; 是最稳妥的选择。它能避开超线程干扰（比如 8 线程 ≠ 8 物理核），也不会在单核云主机上误启多个进程引发上下文切换风暴。生产环境强烈推荐此写法，省心且适配性强。
手动设置时盯紧物理核数，别看逻辑核
查真实物理核心数用命令：
lscpu | grep "Core(s) per socket" && lscpu | grep "Socket(s)"
两者相乘即为物理核总数。例如 2 路 × 6 核 = 12 物理核 → 初始可设为 12。
- 但静态资源服务属于典型 I/O 密集型：大量读文件、发包、等待磁盘或网络响应
- 这类场景下，4～8 个 worker 进程往往已逼近性能拐点，再多提升极小，反而增加调度开销
- 压测时若发现 CPU idle 高但 QPS 上不去，才考虑小幅上调；反之若 CPU 持续 >90%，应先检查磁盘 I/O 或网络带宽瓶颈
容器与云环境必须显式指定
在 Docker 或 K8s 中，auto 会读取宿主机核数，但实际被 cgroups 限制。务必按分配的 vCPU 数设置：
- 分配了 2 vCPU → 写 worker_processes 2;
- 云主机只配 1 核 → 绝对不要写 4 或 8，否则上下文切换吃光 CPU
- 同步调整配套参数：worker_rlimit_nofile 65535; 和 events { worker_connections 65535; }
别忘了绑定 CPU 提升缓存命中率
当 worker 数 ≥ 4 且服务器核数充足时，加上 worker_cpu_affinity auto;（Nginx 1.12.0+ 支持）可让每个进程固定运行在独立核心上，减少 L2/L3 缓存失效。旧版本可用二进制掩码方式，例如 4 核写成：
worker_cpu_affinity 0001 0010 0100 1000;
