worker_processes 应设为 CPU 核心数或 auto，避免超核引发上下文切换、惊群效应和内存浪费；容器化等特殊场景需手动调整，并配合 worker_cpu_affinity 等参数优化。
worker_processes 直接影响 Nginx 处理请求的并行能力，合理设置能显著缩短响应时间——不是靠“堆进程”，而是让每个 CPU 核心真正忙起来、少切换、少争抢。
为什么 worker_processes 能缩短响应时间
每个 worker 进程是独立的事件循环，单核上跑多个 worker 会造成频繁上下文切换；而一个 worker 绑定一个核心，能充分利用 L1/L2 缓存、减少跨核迁移开销。实测中，从 1 个进程改为匹配核心数后，P95 响应延迟常可下降 30%～60%，尤其在高并发短连接场景下效果更明显。
设多少才真正提升响应速度
- 首选 auto：Nginx 1.3.8+ 支持，自动读取逻辑核心数（含超线程），适配物理机、云主机和大多数容器环境
-
手动指定时，用 nproc 输出为准：比如
nproc返回 8，就设worker_processes 8；不要看/proc/cpuinfo里可能被虚化的值 -
容器或混部场景要减量：K8s 限制了 2 vCPU？那就设
worker_processes 2；若同服务器还跑着数据库，可预留 1～2 核，设为$(nproc --all)-2 - 别盲目翻倍：设成 16 核机器的 32，并不会提速，反而因惊群效应和锁竞争拉高延迟
光设对还不行：必须配合的关键动作
-
绑定 CPU 核心：加
worker_cpu_affinity auto;（Nginx 1.9+）或显式写如worker_cpu_affinity 0001 0010 0100 1000;，减少 cache miss -
调高文件句柄上限：每个 worker 需要大量 socket 和文件描述符，配
worker_rlimit_nofile 65535;并确保系统 ulimit -n ≥ 该值 - 匹配 worker_connections：总并发能力 = worker_processes × worker_connections，建议单 worker 至少支持 2048 连接，避免连接排队等待
-
关闭 accept_mutex（新版本默认已优化）：Nginx 1.9.1+ 默认启用更高效的 EPOLL ET 模式，无需额外配置，旧版本可加
accept_mutex on;缓解惊群
怎么验证它真起作用了
改完配置后，用 nginx -t && nginx -s reload 生效，再观察三项指标：
- top 或 htop 中各 worker 进程的 CPU 占比是否均衡（而非全挤在 0 号核）
- ab 或 wrk 压测时的 QPS 和延迟波动是否收窄（P99 延迟下降且抖动变小）
- nginx status 或 stub_status 中 Active connections 分布是否均匀（各 worker 处理连接数接近）
