worker_processes应设为CPU物理核心数，而非逻辑核数；4核物理CPU设为4，超线程增益有限且易引发缓存争用；容器中须手动指定并配合worker_cpu_affinity绑核，否则调度干扰会导致QPS下降5%～15%。
worker_processes 不是“设多就快”，而是要让每个 worker 稳定跑在独立物理核心上，减少调度干扰和缓存抖动。配错反而拖慢响应，尤其在高并发场景下。
worker_processes 数量怎么定
优先按物理核心数设置，不是逻辑核（含超线程）——4 核物理 CPU 就设 4，哪怕系统显示 8 个逻辑核。超线程对 Nginx 这类 I/O 密集型服务增益有限，还容易引发 L2 缓存争用和 TLB 刷新开销。
- 查物理核数：用 lscpu | grep "Core(s) per socket" 或 nproc --all 对比确认
- 静态配置更稳妥：worker_processes 4;（适合明确知道 vCPU 分配的容器/K8s 环境）
- auto 模式慎用：worker_processes auto; 在物理机上可用，但在容器里会读宿主机核数，可能静默降级为单核运行
- 负载类型影响微调：后端延迟高（如慢 API）时，可略高于物理核数（如 ×1.2），但超过 1.5 倍通常得不偿失
必须配合 worker_cpu_affinity 绑核
光设进程数没用。不绑定时，Linux 调度器会动态迁移 worker，导致缓存预热失效、跨 NUMA 访问、SSL 会话缓存抖动，实测 QPS 可能下降 5%～15%。
- 绑核写法示例（4 核）：worker_cpu_affinity 0001 0010 0100 1000;
- Nginx 1.9.10+ 支持 auto 模式：worker_cpu_affinity auto;，能自动避开超线程对，优先分配物理核
- 容器环境注意：若只分到 2 个 vCPU，worker_cpu_affinity 必须只写两组掩码（如 01 10），否则启动失败或退化运行
- 验证是否生效：taskset -cp $(pgrep -f "nginx: worker") 查每个 worker 实际绑定的 CPU ID
连接能力与系统资源要同步跟上
worker_processes × worker_connections 是理论上限，实际被三重限制卡死：文件描述符、内核监听队列、内存占用。
- worker_connections 建议设为 4096～10240，不要盲目拉到 65535
- 系统级 ulimit -n 至少 ≥ worker_processes × worker_connections × 1.2（预留日志、上游连接等）
- /etc/security/limits.conf 中为 nginx 用户加：nginx soft nofile 65535 和 nginx hard nofile 65535
- nginx.conf 主块加：worker_rlimit_nofile 65535;
- 内核参数同步调：net.core.somaxconn = 65535，避免新连接在进入 Nginx 前就被丢弃
NUMA 架构下要额外留意
双路或多路服务器不能只看总核数。若 worker 跨 NUMA 节点访问远端内存，延迟飙升，吞吐反降。
- 先执行 numactl --hardware 查节点布局（如 Node 0: CPU 0–15, Node 1: CPU 16–31）
- 按节点均分 worker：32 核双路机器，设 worker_processes 16，再分两组绑定各自节点的 CPU
- 不建议跨节点绑核，除非业务对延迟不敏感且内存带宽充足
