推荐设为 worker_processes auto；nginx 1.3.8+ 会自动读取逻辑 cpu 核数（如 8 核启 8 进程），避免手动配置误差；必须配合 worker_cpu_affinity 绑定核心、worker_connections 与系统 ulimit -n 协同调优，才能真正用满多核资源。
worker_processes 直接决定 Nginx 能否用满 CPU 多核资源，配少了浪费算力，配多了反而因频繁切换拖慢响应。核心不是“越多越好”，而是让每个工作进程稳定绑定一个逻辑 CPU 核心。
怎么设才合理
推荐直接写 worker_processes auto; —— Nginx 1.3.8+ 版本会自动读取系统逻辑 CPU 核数（比如 8 核就启 8 个进程），省去手动查、手动改的步骤，也避免版本升级后配置失效。
如果必须手动指定，就用 nproc 命令确认逻辑核数：
- nproc 输出是 4 → 设为 worker_processes 4;
- 输出是 16 → 设为 worker_processes 16;
除非业务明显 I/O 密集（如大量静态文件传输、反向代理转发），否则不建议超过逻辑核数。CPU 密集型场景（如高负载 SSL 解密）超配反而导致性能下降。
CPU 绑定不能少
光设对进程数还不够。Linux 调度器可能把多个 worker 进程调度到同一个核心上，造成缓存抖动和上下文切换开销。启用 worker_cpu_affinity 能强制“1 进程 ↔ 1 核心”：
- 4 核服务器：worker_cpu_affinity 0001 0010 0100 1000;
- 8 核服务器：worker_cpu_affinity 00000001 00000010 … 10000000;（共 8 组）
二进制位位置对应 CPU 编号（从右往左，最低位是 core 0），每组数字数量必须与 worker_processes 数量一致。
连带要调的两个关键参数
worker_processes 不是孤立参数，它和下面两个配置共同决定实际并发能力：
- worker_connections：每个 worker 最大连接数，默认 1024。生产环境建议调高（如 10240），但需同步提升系统文件描述符限制（ulimit -n 至少设为 worker_processes × worker_connections × 2）
- use epoll;：放在 events 块里，确保 Linux 下使用高效事件模型。没这句，高并发时性能会断崖下跌
总并发理论值 = worker_processes × worker_connections，但真实上限受内存、网络带宽和后端服务响应速度制约。
怎么验证生效了
别只看配置文件写了什么，得确认实际运行状态：
- 执行 ps aux | grep nginx，看到 1 个 master + N 个 worker 才算成功（N 就是你设的数值）
- 用 htop 或 top -H 观察各 worker 进程的 CPU 分布，理想状态是每个核心负载均衡，没有单核打满其余空闲
- 压测时观察 nginx -s reload 后是否平滑过渡（旧进程自然退出，新进程无缝接管），这是主从模型健壮性的基本体现
