worker_processes 必须设为cpu物理核心数并配合worker_cpu_affinity绑定，否则多核反成干扰源；超线程不增加真实算力，32核服务器设64会引发缓存争用；推荐auto（≥1.9.10）或显式设物理核数，再配numa隔离与文件描述符上限。
worker_processes 不是填个数字就能提升性能的参数，它必须和 CPU 物理拓扑、调度行为、系统资源限制形成闭环，否则多核反而变成干扰源。
按物理核心数设值，别被超线程带偏
Nginx 是 I/O 密集型服务，SSL 解密、gzip 压缩、连接管理等操作更依赖真实执行单元。超线程（HT）只是并发执行能力，并不增加 L1/L2 缓存或计算资源。在 32 物理核 + 64 逻辑核的机器上设为 64，容易引发缓存争用和 TLB 刷新加剧。
- 查真实物理核心总数：nproc --all 或 lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，相乘得出（例如 2 sockets × 16 cores = 32）
- 推荐写法：worker_processes auto;（Nginx ≥ 1.9.10），它能识别物理核并自动跳过超线程对称核
- 若需显式控制（如容器限核场景），直接写 worker_processes 32;，而非 64
必须配合 worker_cpu_affinity 绑定才真正生效
只设进程数却不绑定，内核仍可能把多个 worker 调度到同一核上，导致缓存抖动、锁竞争，甚至退化成单核运行。
- 通用写法：worker_cpu_affinity auto;（Nginx ≥ 1.9.10），自动分配且避开超线程干扰
- 手动配置示例（8 核）：worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
- 掩码组数必须与 worker_processes 数量严格一致——少一组，后面 worker 失去控制；多一组，Nginx 启动失败
NUMA 架构下要分节点均分并隔离
双路或多路服务器中，跨 NUMA 节点访问内存延迟可翻倍。不能只看总核数，而要按节点组织资源。
- 先查布局：numactl --hardware（例如 Node 0: CPU 0–15，Node 1: CPU 16–31）
- 设 worker_processes 16;（每节点 16 核），再用两组 affinity 分别绑定
- 进阶做法：用 numactl --cpunodebind=0 --membind=0 nginx 启动主进程，强制 CPU 与本地内存对齐
配套资源必须同步拉满，避免“有核无粮”
worker 进程数翻倍，但连接上限或文件描述符没跟上，实际并发能力依然卡死。
- 每个 worker 连接数建议设为 worker_connections 4096;（静态资源可更高）
- 主块中加：worker_rlimit_nofile 65535;
- 系统级配置：/etc/security/limits.conf 中为 nginx 用户添加：
nginx soft nofile 65535
nginx hard nofile 65535
