NUMA架构下Nginx性能瓶颈在于跨节点内存访问延迟，有效调优是让每个worker进程严格绑定本地CPU与本地内存：需先用lscpu、numactl --hardware和cat /sys/devices/system/node/node*/cpulist确认拓扑；worker_processes设为单节点物理核数（如双路16核/节点则设16），禁用auto；worker_cpu_affinity按节点分段配置；必须用numactl --cpunodebind --membind启动；最终通过numastat验证local_node>95%、numa_foreign≈0。
在 NUMA 架构服务器上，Nginx 的性能瓶颈通常不是 CPU 不够，而是 worker 进程跨节点访问远端内存——这会让延迟翻倍甚至更高。真正有效的配置，是让每个 worker 只用本地 CPU + 本地内存，切断 QPI/UPI 总线争抢。
先确认真实 NUMA 拓扑，别猜
不能靠逻辑核数或“auto”推断，必须执行三步验证：
- lscpu | grep -E "(Socket|Core|NUMA)" → 查清插槽数（Socket）、每槽物理核数、NUMA 节点总数
- numactl --hardware → 看每个 node 的 CPU 编号范围（如 node 0: CPUs 0–15）和本地内存容量
- cat /sys/devices/system/node/node*/cpulist → 精确到每个核心归属，避免掩码错位
特别注意：如果 BIOS 中启用了 Node Interleaving，numactl --hardware 会显示单个大节点，实际已失去 NUMA 局部性——必须进 BIOS 关闭该选项。
worker_processes 必须设为单节点物理核数
例如双路服务器，每路 16 物理核（共 32 核），应设：
- worker_processes 16（对应 node 0 或 node 1 的物理核数）
- 更稳妥可设为 8～12，留出资源给系统中断、软中断和后台进程
- 禁用
worker_processes auto：它只读/proc/cpuinfo总数，不感知 NUMA 边界，实测易导致一半 worker 跑在远端节点，numa_foreign明显升高 - 不要设为 32（总物理核）或 64（超线程总数）：前者可能触发跨节点调度，后者加剧 L3 缓存争用
CPU 和内存绑定必须同步生效
仅靠 worker_cpu_affinity 绑定 CPU 是不够的，Nginx 自身无法控制 malloc 分配的内存落在哪个 node：
-
worker_cpu_affinity 要按节点分段写。例如 node 0 有 CPU 0–15，可用 16 位掩码：
worker_cpu_affinity 0000000000000001 0000000000000010 ...（共 16 组） -
必须用 numactl 启动主进程，强制内存亲和：
/usr/bin/numactl --cpunodebind=0 --membind=0 /usr/sbin/nginx -g 'daemon on; master_process on;' - 若需双节点部署，可用
--cpunodebind=0,1 --membind=0,1，但更推荐单节点部署 + 外部负载分发，避免共享内存区跨节点访问
验证是否真正落地，看内存路径而非 CPU ID
不能只看 ps 或 taskset 输出的 CPU 绑定结果：
- 运行
numastat -p $(pgrep nginx) - 重点看
local_node是否 >95%，numa_foreign是否 ≈ 0 - 若
foreign明显非零，说明仍有跨节点内存分配，需回查 BIOS 设置、numactl 参数或掩码范围
