worker_processes 不是越多越好，应设为物理核心数并配合worker_cpu_affinity绑定，避免超线程干扰和跨NUMA访问；需同步调优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 个），再用 numactl --cpunodebind=0 --membind=0 启动主进程
- 验证：numastat -p $(pgrep nginx)，local_node 应 >95%，foreign 接近 0
