worker_processes 应设为物理核心数而非逻辑核数，配合worker_cpu_affinity绑定CPU亲和性，并在NUMA架构下按节点均分，同时调高文件描述符限制，才能真正发挥多核性能。
worker_processes 不是随便填个数字就能提升性能的参数，它的价值在于让每个 Nginx 工作进程与物理 CPU 核心形成稳定、低干扰的映射关系。配得准，才能把多核真正用起来；配得偏，反而引发调度抖动、缓存失效甚至跨 NUMA 访问延迟。
按物理核心数设值，不是逻辑核或超线程数
超线程（HT）提供的只是并发执行能力，并不能增加真正的计算单元。Nginx 是 I/O 密集型服务，SSL 解密、gzip 压缩、连接管理等操作更依赖物理核心的执行资源。在 32 物理核 + 64 逻辑 CPU 的服务器上，设为 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; - 严禁多个 worker 绑定同一物理核——不仅绑定失效，还可能触发锁竞争
NUMA 架构下要分节点均分并隔离
双路或多路服务器中，CPU 和内存是按节点组织的。若 worker 跨节点访问远端内存，延迟可飙升 50% 以上，吞吐不升反降。
- 先执行
numactl --hardware查布局，例如：
Node 0: CPU 0–15，本地内存 64GB
Node 1: CPU 16–31，本地内存 64GB - 设
worker_processes 16;（每节点 8 个），再用两组掩码分别绑定：worker_cpu_affinity 0000000000000001 0000000000000010 ...（共 8 组，对应 Node 0）worker_cpu_affinity 00000000000000010000000000000000 ...（共 8 组，对应 Node 1） - 进阶：用
numactl --cpunodebind=0 --membind=0 nginx启动，强制内存亲和
同步调高资源上限，避免“有核无粮”
worker 进程数翻倍，但单个 worker 最大连接数（worker_connections）没跟上，或系统文件描述符限制太低，实际并发能力依然卡死。
- 单 worker 连接数建议设为 4096～65535（静态资源轻量场景可更高）
- 系统级 ulimit -n 至少 ≥
worker_processes × worker_connections，例如 32 × 4096 = 131072 - nginx.conf 主块中加：
worker_rlimit_nofile 131072; - 确认
use epoll;和multi_accept on;已启用
