worker_processes 必须绑定物理核心才能发挥性能，应设为物理核心数并配合worker_cpu_affinity；容器/K8s中需根据cgroup配额显式设置，且需调优系统参数如ulimit和epoll。
worker_processes 不是孤立的数字，它必须和 Linux 调度器协同工作才有意义。设对数量只是第一步，关键在于让每个 worker 稳定运行在专属物理核心上，避免被调度器来回迁移。
绑定物理核心比单纯设数量更重要
Linux 默认按负载均衡调度进程，一个 worker 可能在不同 CPU 核之间跳来跳去。这会导致 L1/L2 缓存反复失效、TLB 刷新增多、SSL 会话缓存命中率下降——即使你设了 8 个 worker，不绑定就等于白调。
- 推荐直接写 worker_cpu_affinity auto;（Nginx 1.9.10+ 支持），自动避开超线程，优先分配物理核心
- 手动指定时，确保每个掩码对应唯一物理核，比如 4 核机器： worker_cpu_affinity 0001 0010 0100 1000;
- 禁止两个 worker 绑定同一物理核，否则会引发锁竞争，失去并行价值
数量要匹配真实可用的物理核心
worker_processes 应等于 CPU 物理核心数，不是逻辑线程数，也不是容器或虚拟机报告的 vCPU 数（除非已明确限制）。
- 查物理核心总数：用 nproc --all 或 lscpu | grep "Core(s) per socket" | awk '{sum += $4} END {print sum}'
- 8c16t 的机器，仍设为 worker_processes 8;，超线程对 Nginx 这类 I/O 密集型服务增益有限
- 双路 32 核服务器 → 设为 32，不是 64；混合部署（如共跑数据库）可预留 1–2 核，设为 $(nproc --all)-2
容器与云环境必须显式设置
auto 在容器里可能读错——Docker 官方镜像虽支持 cgroups 检测，但 Kubernetes 中若未启用 cgroups v2 或资源限制未生效，auto 仍会取宿主机核数，导致启动过多 worker 并争抢资源。
- K8s Pod 设置了 resources.limits.cpu: "2"，就必须写死 worker_processes 2;
- Docker 启动时加环境变量：-e NGINX_ENTRYPOINT_WORKER_PROCESSES_AUTOTUNE=1，触发镜像内 30-tune-worker-processes.sh 自动识别 cgroup 配额
- 验证是否生效：运行 ps -eo pid,psr,comm | grep nginx，看各 worker 是否固定在指定 CPU 编号上
配套系统级参数不能漏
worker_processes 起效的前提，是系统允许它打开足够多连接、使用足够内存，并走高效事件模型。
- worker_rlimit_nofile 至少设为 worker_connections 的值（如 65535）
- 系统 ulimit -n 至少设为 worker_processes × worker_connections × 1.2
- events 块中启用 use epoll; 和 multi_accept on;，避免回退到低效 select/poll
