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 会话缓存、共享内存锁、文件元数据等热点数据才能长期驻留本地缓存，降低跨核访问延迟。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 通用写法：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; 已启用