nginx worker_processes 应设为 auto（推荐）或严格匹配物理核心数，避免过少导致多核闲置、过多引发调度开销；必须配合 worker_cpu_affinity 绑定 cpu、调高文件描述符限制，并在 numa 架构下按节点分组配置以确保内存本地化。
worker_processes 设置直接决定 Nginx 能否把请求均匀分发到多个 CPU 核心上。设少了，多核空转；设多了，反而因调度争抢拖慢整体响应。关键不是数字本身，而是进程与物理核心的稳定绑定关系。
设太少：单核扛不住，其余核心全闲置
比如 16 核服务器只配 worker_processes 1，所有连接都挤在一个进程里。即使单进程能处理上万连接，CPU 利用率也只跑满 1 个核心，其余 15 核完全没参与工作。QPS 上不去，延迟明显升高，尤其在 API 网关这类短连接密集场景下更突出。
典型表现：
• top 中 %us 很低，但响应时间高、%wa 上升
• ps 查到只有 1 个 worker 进程在运行
• 仅适用于极低流量测试机或内存严重受限设备（如 512MB VPS 可设为 1～2）
设太多：调度开销反超收益
超过逻辑核心数后，内核频繁做上下文切换，每个 worker 都要独立加载配置、维护连接状态、分配缓冲区，内存占用线性增长，CPU 时间片大量消耗在切换上，而非处理请求。
常见问题：
• sy%（系统态 CPU）持续高于 10%，cs（上下文切换）突破 5 万/s
• 多个 worker 同时竞争 accept、共享内存锁、日志写入等资源
• cache-misses 比例升高，L1/L2 缓存命中率断崖下降
• 在 32 物理核 + 超线程的机器上设为 64，实测 QPS 反比设为 32 低 5%～15%
设得准：auto + 绑核 + 资源协同才是正解
推荐优先使用 worker_processes auto;（Nginx 1.9.10+），它能自动识别 NUMA 架构并按物理核心分配，比手动计算更稳妥。但光设对数量远远不够，必须同步做三件事：
- 绑定核心：加 worker_cpu_affinity auto;，让每个 worker 固定运行在专属物理核上，避免跨核缓存失效
- 放宽文件描述符限制：确保 worker_rlimit_nofile 和系统级 ulimit -n 匹配，例如 32 个 worker × 4096 连接 → 至少需 131072
- 适配运行环境：容器中按 cgroups 实际 vCPU 数显式设置（如 K8s limits.cpu: "4" → 写 worker_processes 4;），别依赖 auto 读宿主机核数
特殊场景要手动干预
auto 不是万能钥匙。以下情况需要针对性调整：
- 与数据库共存：预留 1～2 核，用 worker_processes $(nproc --all)-2
- 双路服务器：先执行 numactl --hardware 查节点布局，按 NUMA 节点分组设置，避免跨节点访问远端内存
- 大量小文件服务且内存不足：可适度提高 worker 数（如 ×1.5），但需同步调低 sendfile 或增大 read_ahead
