Nginx worker_processes 应设为物理核心数而非逻辑核数，如双路16核服务器为32核；超线程对I/O密集型服务增益有限且易引发缓存争用，需配合worker_cpu_affinity绑定CPU亲和性，并同步调优ulimit、net.core.somaxconn等系统参数。
直接设成 64 不仅没用，反而容易拖慢响应。真正有效的调优，是让每个 worker 稳定跑在独立物理核心上，减少调度干扰和缓存抖动。
明确物理核数，而非逻辑核或 vCPU 总数
2 路 × 16 核 = 32 物理核，不是 64。超线程（HT）对 Nginx 这类 I/O 密集型服务增益有限，还易引发 L2 缓存争用和 TLB 刷新开销。盲目设为 64，会显著增加进程切换、锁竞争与缓存失效频率。
- 查物理核心数：用 lscpu | grep "Core(s) per socket" 或 nproc --all 对比确认
- 云/容器环境特别注意：/proc/cpuinfo 可能不准，nproc 输出才是真实分配的 vCPU 数
- 双路或多路服务器需留意 NUMA：跨节点访问远端内存会导致延迟飙升，吞吐反降
进程数设定要匹配实际资源，不建议“一步到位”
worker_processes 不是“越多越好”，而是要与 CPU 实际可用资源精准匹配。设太小，多核闲置；设太大，调度开销压垮性能。
- 物理机推荐：设为物理核心总数，例如 32 核就设 worker_processes 32
- 混合部署场景（如同时跑 MySQL）：预留 1–2 核，设为 $(nproc --all)-2
- 容器/K8s 环境：必须显式写死，例如只分到 2 核就写 worker_processes 2，避免 auto 读宿主机 64 核导致静默降级
- 后端延迟高（如慢 API）时可略高于物理核数（如 ×1.2），但超过 1.5 倍通常得不偿失
必须绑定 CPU 亲和性，否则调对也白搭
只设进程数不绑核，Linux 调度器仍可能把多个 worker 挤在同一核，或频繁迁移，导致缓存预热失效、SSL 会话抖动、跨 NUMA 访问——实测 QPS 下降 5%～15%。
- 双核写法：worker_cpu_affinity 01 10
- 四核简洁写法（Nginx 1.9.10+）：worker_cpu_affinity auto（自动避开超线程对，优先物理核）
- 容器中若只分到 2 vCPU，掩码只能写两组（如 01 10），否则启动失败或退化运行
- 验证是否生效：taskset -cp $(pgrep -f "nginx: worker")
配套系统与连接参数同步跟上
worker_processes × worker_connections 是理论上限，但真正卡住你的往往是系统级瓶颈。
- 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 前就被丢弃
- events 块推荐：worker_connections 4096～10240，use epoll，multi_accept on
