worker_processes应设为cpu物理核心数，必须配合worker_cpu_affinity绑定独立物理核，否则调度器频繁迁移会导致缓存失效、tlb刷新增多；容器环境须按vcpu配额显式设置，禁用auto以防误读宿主机核数。
worker_processes 本身不直接控制调度，真正起作用的是它与 Linux 调度器的协同方式——关键在于“进程数量 + CPU 绑定 + 内核调度策略”三者配合，否则 worker 进程会被动态迁移，破坏缓存局部性，反而拖慢性能。
必须绑定 CPU，否则调度器会“乱分配”
Linux 默认按负载均衡原则调度进程，一个 worker 可能在不同核心间频繁切换。这会导致 L1/L2 缓存反复失效、TLB 刷新增多、SSL 会话缓存命中率下降。即使设了正确的 worker_processes 数量，不绑定就等于没调优。
- 推荐写法：worker_cpu_affinity auto;（Nginx 1.9.10+ 支持），自动避开超线程对，优先分配物理核心
- 手动指定时，确保每个掩码对应唯一物理核，例如 4 核机器：worker_cpu_affinity 0001 0010 0100 1000;
- 禁止两个 worker 绑定同一物理核——会引发锁竞争，且失去并行意义
数量要匹配物理核心，而非逻辑核或 vCPU
worker_processes 不是越多越好。Nginx 是 I/O 密集型服务，超线程带来的收益有限，反而加剧缓存争用。重点是让每个 worker 稳定运行在独立物理核心上，减少调度干扰。
- 查真实物理核数：nproc --all 或 lscpu | grep "Core(s) per socket" × socket 数
- 双路 32 物理核服务器 → 设 worker_processes 32，不是 64
- 容器环境（如 K8s）中，auto 会读宿主机核数，必须显式设为资源限制的 vCPU 数，例如 worker_processes 2;
避免调度器“惊群”和上下文切换开销
所有 worker 共享监听端口时，内核通知多个进程 accept 新连接，会造成惊群效应。虽然 Nginx 1.9.1+ 默认启用 accept_mutex 缓解，但 worker 过多仍会放大调度压力。
- 不建议设为物理核数的 2 倍以上，例如 16 核设 32 个 worker，QPS 反而可能下降 5%～15%
- 混合部署场景（如共用机器跑 DB 或 Java 应用），可预留 1–2 核，设为 worker_processes $(nproc --all)-2
- 高延迟上游（如慢速后端）可略增 worker，但优先优化 upstream timeout 和 retry，而非盲目加进程
配套系统级调度辅助不可少
仅靠 Nginx 配置不够，还需操作系统层面配合，让调度器“知道”该怎么做：
- worker_rlimit_nofile 65535; —— 让每个 worker 能打开足够文件描述符，避免被 ulimit 卡住
- 在 /etc/security/limits.conf 中为 nginx 用户设硬限制：nginx soft nofile 65536、nginx hard nofile 65536
- NUMA 架构下（如双路服务器），执行 numactl --hardware 查节点布局，按节点分组设置 worker_processes 和 affinity，避免跨节点内存访问
