Nginx worker_processes 应基于物理CPU核心数设定，I/O密集型可设1～4，CPU密集型建议等于物理核数，启用auto时需加上限；调优需结合CPU使用率、连接数与上下文切换等指标验证。

Nginx 的 worker_processes 设置直接影响并发处理能力和资源利用率。设得过少，CPU 空转、请求排队；设得过多，进程调度开销增大，反而降低吞吐。最佳值不是固定数字，而是需结合 CPU 核心数、是否启用超线程、工作模式（CPU 密集 or I/O 密集）以及实际负载特征来动态判断。

看准 CPU 物理核心数，不是逻辑处理器数

Linux 下执行 nproc --all 返回的是逻辑 CPU 数（含超线程），但 Nginx worker 进程是重量级的，每个默认独占一个 CPU 核心更稳定高效。推荐优先用物理核心数：

• 查物理核心总数：lscpu | grep "Core(s) per socket" && lscpu | grep "Socket(s)"，相乘即得
• 例如：2 路 CPU × 8 核/路 = 16 物理核 → 初始 worker_processes 16
• 若启用了超线程（HT），逻辑核为 32，不建议直接设成 32；高 I/O 场景可尝试 16～24，但需压测验证

区分使用场景：CPU 密集型 vs I/O 密集型

Nginx 大部分时间在做网络收发和磁盘读写（I/O 密集），而非复杂计算。因此通常无需与物理核一一绑定：

• CPU 密集型（如大量 SSL/TLS 加解密、gzip 压缩、Lua 脚本运算）：建议 worker_processes auto 或设为物理核数，避免上下文切换浪费
• I/O 密集型（静态文件服务、反向代理、缓存命中率高）：worker_processes 1～4 常已足够；多进程主要提升连接分发和中断响应能力，非算力需求
• 混合型业务（如 HTTPS + 动态 upstream）：从物理核数起步，再通过 ab 或 wrk 对比 QPS 和 CPU idle 率微调

善用 auto 模式并限制上限

worker_processes auto 是 Nginx 1.3.8+ 提供的智能选项，它会读取 /proc/cpuinfo 并默认设为逻辑 CPU 数。但生产环境建议加兜底：

• 配置示例：worker_processes auto; worker_cpu_affinity auto;
• 为防虚拟机或容器中暴露过多 vCPU（如云主机标称 32vCPU，但实际共享物理资源），可手动限定：
  worker_processes 8; # 显式设上限
• 搭配 worker_rlimit_nofile 和 events { use epoll; worker_connections 4096; } 才能真正释放多进程潜力

验证与调优：别只看配置，要看指标

设完不等于调优完成。关键看三项运行时指标：

• CPU 用户态使用率（top 中 %us）：持续 > 70% 且 worker_processes 较低 → 可增；若已达物理核数仍高，说明瓶颈在代码或上游
• Nginx worker 进程数与活跃连接比：用 nginx -T | grep worker_processes + ss -s | grep "estab" 粗略估算，理想状态是每个 worker 处理 1k～3k 并发连接
• 上下文切换（cs）和运行队列（r）：vmstat 1 中若 cs > 10k/s 且 r > CPU核数×2，大概率是 worker 过多导致争抢