worker_processes 应设为物理核心数而非逻辑核数，推荐使用 auto 并配合 worker_cpu_affinity 绑定；需同步调优 worker_connections、ulimit 和 numa 亲和性以避免性能下降。
worker_processes 不是“开越多越好”，而是要让每个 worker 稳定运行在独立物理核心上，减少调度干扰和缓存抖动。关键不在数量本身，而在进程与硬件资源的精准匹配。
按物理核心数设置，而非逻辑核或超线程数
高核服务器（如 32 物理核 + 超线程共 64 逻辑 CPU）容易误配过高数值。Nginx 是 I/O 密集型服务，超线程带来的收益有限，反而加剧 L1/L2 缓存争用和 TLB 刷新。
- 用 nproc 或 lscpu | grep "Core(s) per socket" 查清物理核心总数
- 32 物理核 → 推荐 worker_processes 32；不建议设为 64
- 更稳妥的做法是写 worker_processes auto;（Nginx 1.9.10+ 支持，能识别 NUMA 并按物理核分配）
必须配合 worker_cpu_affinity 实现核心绑定
只设对进程数不够，不绑定就等于没调优。绑定后，SSL 会话缓存、共享内存锁、文件元数据等热点数据才能长期驻留本地缓存，降低跨核访问延迟。
- 通用写法：worker_cpu_affinity auto;（自动错开超线程对，优先分配物理核）
- 精细控制示例（32 核）：worker_cpu_affinity 00000001 00000010 ...（共 32 组掩码）
- 禁止多个 worker 绑定同一物理核——否则绑定失效，还可能引发锁竞争
同步提升连接能力与系统资源上限
高核数若搭配低 worker_connections 或系统文件描述符限制，实际并发仍上不去，甚至报 “too many open files”。
- 单 worker 连接数可设为 2048～4096（静态资源轻量，可适当提高）
- 系统级 ulimit -n 至少 ≥ worker_processes × worker_connections
- /etc/security/limits.conf 中为 nginx 用户添加：
nginx soft nofile 65535
nginx hard nofile 65535 - nginx.conf 主块中加：worker_rlimit_nofile 65535;
NUMA 架构需额外做节点隔离
双路或多路服务器不能只看总核数。若 worker 跨 NUMA 节点访问远端内存，延迟飙升，吞吐反降。
- 执行 numactl --hardware 查节点布局（如 Node 0: CPU 0–15，Node 1: CPU 16–31）
- 设 worker_processes 16（每节点 8 个），再用 worker_cpu_affinity 分别绑定两组 CPU
- 用 numactl --cpunodebind=0 --membind=0 启动 Nginx，强制内存亲和（需通过 systemd 封装或启动脚本）
- 验证用 numastat -p PID，确认本地节点内存占比 >95%
