双路或多路numa服务器上worker_processes必须按单节点逻辑核数设置（如每节点32核则设32），禁用auto；需结合worker_cpu_affinity分组绑定cpu与numactl强制本地内存亲和，实测静态qps可提升90%以上。
在双路或多路 NUMA 服务器上，worker_processes 不能只看总逻辑核数——必须与 NUMA 节点物理布局对齐，否则静态文件转发（如图片、JS、CSS）会因跨节点内存访问导致延迟翻倍、QPS 卡在瓶颈。实测显示，正确 NUMA 感知配置可使静态 QPS 提升 90% 以上。
先确认真实 NUMA 拓扑，别信“auto”或“nproc”
执行以下命令获取硬件级分布，而非操作系统报告的逻辑核总数：
- numactl --hardware：查看 node 数量、各 node 的 CPU 列表和本地内存容量（例如 node 0: CPUs 0–31, 64GB；node 1: CPUs 32–63, 64GB）
- lscpu | grep -E "(Socket|NUMA)"：验证插槽数与 NUMA 节点是否一一对应
- cat /sys/devices/system/node/node*/cpulist：精确到每个 node 绑定哪些 CPU ID
重点看 CPU 编号是否连续分组、内存是否本地化。若 BIOS 中启用了 Node Interleaving，需关闭，否则 numactl 显示“单节点”，实际内存已交错，亲和性失效。
worker_processes 数量按单个 NUMA 节点逻辑核设，不是总核数
例如双路 32 核（每路 16 物理核 + 超线程共 32 逻辑核），典型拓扑为：
- Node 0：CPU 0–31，本地内存 64GB
- Node 1：CPU 32–63，本地内存 64GB
此时应设：
- worker_processes 32;（即单节点逻辑核数，非总核数 64）
- 禁用 worker_processes auto —— 它在 Nginx ≤1.19.9 中无 NUMA 感知，仅读 /proc/cpuinfo 总数；即使新版支持，也建议显式设定以避免容器或隔离环境误判
绑定 CPU + 强制内存亲和，缺一不可
CPU 绑定只是第一步，必须同步约束内存分配路径：
- 用 worker_cpu_affinity 按 NUMA 节点分组写掩码，确保每个 worker 只跑在本地 node 的核心上：
worker_cpu_affinity 00000001 00000010 00000100 ... ; # 前 32 项，每位对应 node 0 的 CPU 0–31
worker_cpu_affinity 0000000100000000 0000001000000000 ... ; # 后 32 项，对应 node 1 的 CPU 32–63（注意位宽匹配） - 更稳妥方式：用 numactl 启动主进程，强制内存来自本地节点：
numactl --cpunodebind=0 --membind=0 /usr/sbin/nginx
或为双节点部署两个独立 master（适合超大规模边缘节点）
验证是否真正生效，不看 CPU 看内存
ps 或 htop 显示 CPU 固定 ≠ NUMA 亲和生效。关键验证点是内存访问局部性：
- 查进程内存分布：numastat -p $(pgrep nginx | head -1)
理想状态：numa_hit > 95%，numa_foreign ，numa_miss ≈ 0 - 压测时观察 perf：perf stat -e mem-loads,mem-stores,cycles,instructions -p $(pgrep nginx | head -1)
若 mem-loads 平均 cycle latency > 200 cycles，大概率存在跨节点访存 - 配套检查：sysctl vm.swappiness=0（禁用 swap 防止跨节点换页）、accept_mutex off; multi_accept on;（减少事件分发锁竞争）
