worker_processes 应设为物理核心数而非逻辑核数，配合worker_cpu_affinity绑定亲和性，并在容器中严格对齐cpu配额；同时需协同调优worker_connections、文件描述符及内核参数。
worker_processes 本身不直接“加速”单个请求，而是让 Nginx 能真正用满多核 CPU——设少了，核心空转；设多了，反而因调度争抢拖慢整体响应。关键不是堆数量，而是让进程数贴合真实算力和负载特征。
按物理核心数设置，别被超线程误导
Nginx 是 I/O 密集型服务，SSL 解密、gzip 压缩、连接管理等更依赖物理执行单元。超线程（HT）只是并发执行能力，并不增加真实计算资源。在 32 物理核 + 64 逻辑核的机器上，设为 64 容易引发 L1/L2 缓存争用和 TLB 刷新加剧。
- 查真实物理核数：
nproc --all或lscpu | grep "Core(s) per socket"× socket 数 - 推荐写法：
worker_processes auto;（Nginx 1.9.10+ 支持，能识别物理核并避开超线程对） - 手动指定示例：32 物理核 →
worker_processes 32;，不建议写 64
必须绑定 CPU 亲和性，否则等于白调
只设对进程数却不绑定，系统调度器仍可能把多个 worker 挤在同一核上，或频繁迁移。绑定后，SSL 会话缓存、共享内存锁、文件元数据等热点数据才能长期驻留本地缓存，降低跨核访问延迟。
- 通用写法：
worker_cpu_affinity auto;（自动错开超线程对，优先分配物理核） - 精细控制（8 核）：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; - 验证是否生效：
taskset -cp $(pgrep -f "nginx: worker")查看每个 worker 实际绑定的 CPU ID
容器与混部场景要严格对齐资源配额
auto 不感知 cgroup 限制，在 Kubernetes 中若只分配了 2 个 vCPU，auto 仍可能拉起 64 个 worker，导致严重资源争抢。
- 容器部署：显式写
worker_processes 2;，与resources.limits.cpu: "2"严格对齐 - 混合负载服务器（如共存数据库）：预留 1～2 核，设为
worker_processes $(nproc --all)-2; - OpenVZ 等平台：nproc 可能固定返回 1，auto 实际退化为单进程，需手动覆盖
配套资源必须同步跟上
worker_processes 是“并行宽度”，但真正承载连接的是 worker_connections。两者共同决定理论最大连接数，而这个值受三重限制：
- 系统级文件描述符上限：
worker_rlimit_nofile 65536;，并确保ulimit -n ≥ 该值 - 内核网络队列长度：
net.core.somaxconn必须 ≥worker_connections - 内存占用预估：每个连接平均消耗 10–20 KB，8 个 worker × 65535 连接 ≈ 10 GB 内存
