worker_processes优化核心是让每个worker稳坐一个CPU核心，推荐设为auto（自动匹配逻辑核数），手动设置时应以nproc输出为准；必须配合worker_cpu_affinity绑定、worker_rlimit_nofile调优及ulimit -n生效，否则易引发调度开销、惊群效应和文件描述符限制。
worker_processes 的优化核心是让每个工作进程“稳坐”一个 CPU 核心，既不闲置也不争抢。设为 auto 是最稳妥的选择，它会自动读取系统逻辑核心数，省去人工误判风险；手动设置时，数值应严格对齐 nproc 输出的逻辑 CPU 数（含超线程），而不是物理核心数。
怎么确定该设多少
别猜，直接查：
- 运行 nproc —— 输出几就是几，这是 Nginx 应该用的数字
- 或用 lscpu | grep "CPU(s):" 看 “CPU(s) per socket × Socket(s)” 和 “Core(s) per socket”，再乘以超线程倍数（通常×2）
- 在容器或云主机中，/proc/cpuinfo 可能不准，必须以 nproc 为准
为什么不能随便填大数
超过逻辑核心数后，性能反而下降，原因很实在：
- 进程调度开销变大，内核频繁切换上下文
- 多个 worker 抢同一个连接时触发“惊群效应”，浪费 CPU
- 锁竞争加剧，尤其在共享资源（如缓存、日志）场景下更明显
- 内存占用上升，每个 worker 都要加载配置、维护连接状态
光设数量还不够
worker_processes 只是第一步，必须配合其他配置才能真正发挥多核能力：
-
加 worker_cpu_affinity：把每个 worker 绑定到固定核心，比如 4 核就写
worker_cpu_affinity 0001 0010 0100 1000;，减少跨核缓存失效 -
调高文件描述符限制：通过
worker_rlimit_nofile 65535;和系统级/etc/security/limits.conf同步放宽，否则 worker_connections 再高也卡在“too many open files” - 检查 ulimit -n：启动 Nginx 前确认当前用户限制已生效，否则配置无效
常见踩坑点
这些错误看似小，但实际压测时立刻暴露：
- 把 worker_processes 设成 16，而服务器只有 4 核 8 线程——白白增加调度负担
- 设了 auto 却没配 worker_cpu_affinity，导致 worker 在不同核心间跳来跳去，L1/L2 缓存命中率暴跌
- 只改了 nginx.conf，忘了改系统 limits，结果并发一上来就报错退出
- 在 Kubernetes Pod 里硬写死 worker_processes 8，但 Pod 只被分配了 2 个 vCPU——资源错配且浪费
