worker_processes 应设为CPU物理核心数，而非逻辑核数；容器环境须按cgroups实际vCPU配额显式设置，并配合worker_cpu_affinity绑定核心、worker_rlimit_nofile提升句柄上限及worker_connections合理调优，才能真正提升CPU利用率。
worker_processes 不决定“往哪转”，但直接决定“能同时转多少路”。设少了，多核 CPU 大部分时间在发呆；设多了，进程来回切换、抢缓存、争锁，反而拖慢整体响应。它不是负载均衡算法的一部分，却是所有转发动作得以并行执行的底层支撑。
匹配物理核心数是最稳妥的起点
4 核 CPU 就设 worker_processes 4，8 核就设 8。不要看 nproc 返回的逻辑核数（含超线程），尤其在启用了 gzip、TLS 加密或高频率代理的场景下，物理核更能避免执行单元和 L2 缓存争抢。验证方式：lscpu | grep -E "Core|Socket"，用 “Core(s) per socket × Socket(s)” 得出真实物理核数。
auto 不是万能，容器和混部环境要手动控制
在 Kubernetes 中若限制了 2 vCPU，worker_processes auto 仍可能读取宿主机核数，导致进程虚高、资源争抢。此时应显式写为 worker_processes 2。同理，若服务器还跑着 MySQL 或 Java 应用，建议预留 1～2 核：worker_processes $(nproc --all)-2。
光设对数量远远不够，必须配套三项关键动作
只调 worker_processes 是无效操作。 必须同步做：
- 启用 CPU 绑定：worker_cpu_affinity auto（Nginx 1.9.10+），让每个 worker 固定运行在专属物理核上，减少缓存抖动
- 提升文件描述符上限：worker_rlimit_nofile 65536，并确保系统级
ulimit -n≥ 该值 - 配平连接能力：worker_connections 要与进程数匹配，例如 4 个 worker 配 10240，理论支持约 40960 并发连接
设错会引发连锁负反馈，不止是慢那么简单
worker_processes = 1 时，所有请求串行排队，P95 延迟可能飙升 3～5 倍；设得过高（如 16 核机器配 32 进程），上下文切换开销上升，sy% 明显升高，实测 QPS 反降 5%～15%。更危险的是：连接被拒绝 → 客户端重试 → 请求堆积 → 后端雪崩，系统负载从 CPU 扩散到网络、磁盘、内存全面承压。
