worker_processes 应设为CPU物理核心数或auto，避免超核引发上下文切换与缓存失效；需配合worker_cpu_affinity绑定、worker_rlimit_nofile及系统ulimit -n协同调优，容器环境须按cgroups实际配额动态设置。
worker_processes 设置直接影响 Nginx 能否真正用满 CPU、是否产生额外开销，不是“越多越好”，也不是“默认就行”，关键在匹配硬件真实能力与业务负载特征。
设太少：单核瓶颈，高并发直接卡死
比如 16 核服务器只设 worker_processes 1，所有请求全挤在一个进程里。即使单 worker 能处理上万连接，CPU 利用率也只跑满 1 个核心，其余 15 核闲置。QPS 上不去，延迟飙升，尤其在短连接密集场景（如 API 网关）下，表现尤为明显。
- 典型症状：top 中 %us 很低，但 %wa 或响应时间很高；ps 查到只有 1 个 worker 进程在跑
- 适用场景极少——仅限极低流量的测试机或内存严重受限的嵌入式设备（如 512MB VPS 可设为 1～2）
设太多：调度开销反超收益，性能不升反降
超过物理核心数后，系统开始频繁做进程调度和上下文切换。每个 worker 都要单独加载配置、维护连接状态、分配缓冲区，内存占用线性增长，CPU 时间片被大量消耗在切换上，而非处理请求。
- 64 逻辑核（32 物理核 + 超线程）设为 64，实测 QPS 可能比设为 32 低 5%～15%
- 惊群效应虽被 accept_mutex 缓解，但未完全消除；锁竞争（如共享内存、SSL 会话缓存）也会加剧
- 每个 worker 的 client_header_buffer_size、open_file_cache 等资源都独立分配，内存压力成倍放大
设得准：物理核数 + 绑定 + 资源协同才是关键
推荐做法不是死记数字，而是让每个 worker 稳定落在一个物理核心上，减少跨核缓存失效和远端内存访问（NUMA 场景下尤为重要）。
-
优先写
worker_processes auto;（Nginx 1.9.10+），它能识别 NUMA 并按物理核分配，比手动算更稳妥 - 必须搭配
worker_cpu_affinity auto;，自动错开超线程对，避免两个 worker 绑同一物理核 - 同步检查：
worker_rlimit_nofile、worker_connections、系统ulimit -n是否匹配（例如 32 个 worker × 4096 连接 → 至少需 131072） - 双路服务器要查
numactl --hardware，按节点分组设置，别让 worker 跨 NUMA 访问远端内存
特殊场景要手动干预
auto 不是万能钥匙，容器、混部、慢上游等场景需要针对性调整。
- 容器环境（如 K8s limits.cpu: "4"）→ 显式设
worker_processes 4，避免 auto 读宿主机核数 - 与数据库共存 → 预留 1～2 核，用
worker_processes $(nproc --all)-2 - 大量反向代理且后端响应慢 → 可略增 worker 数（如物理核数 ×1.2），但优先优化 upstream timeout 和 keepalive
