Worker进程数应严格匹配物理核心数而非逻辑核数，推荐使用worker_processes auto;配合worker_cpu_affinity auto;实现CPU亲和绑定，并在NUMA架构下按节点隔离，同时提升worker_connections与系统文件描述符限制以支撑高并发。
Worker 进程不是越多越好，关键在于让每个进程稳定运行在独立物理核心上，避免调度干扰、缓存抖动和跨 NUMA 访问延迟。真正起作用的不是数字本身，而是进程与 CPU、内存、I/O 资源之间的精准匹配。
Worker 进程数必须对齐物理核心
超线程（HT）不能增加真实计算单元，Nginx 是 I/O 密集型服务，SSL 解密、gzip 压缩、连接管理等操作更依赖物理核心执行能力。设得过高反而加剧 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 个），再用两组掩码分别绑定 - 进阶方式：用
numactl --cpunodebind=0 --membind=0 nginx启动，强制内存亲和
配套资源必须同步提升
高核数若搭配低连接能力或系统限制，实际并发仍卡死。常见报错 “too many open files” 就是典型信号。
-
worker_connections建议设为 10240 或更高（如 32768） -
worker_rlimit_nofile 100000;提前声明 Worker 可打开的最大文件数 - Linux 系统同步调整：
ulimit -n 100000，并在/etc/security/limits.conf中持久化 - 公式参考：理论最大并发 =
worker_processes × worker_connections，实际预留 20%～30% 冗余
