根本原因是NUMA架构下跨节点访问需经UPI/QPI总线，路径更长、协议开销大；实测本地延迟约10ns，跨一节点升至16–22ns（增幅60%–180%），跨两节点达28–37ns。
跨 CPU 访问变量内存时出现显著延迟，根本原因在于 NUMA 架构下内存访问路径的物理不一致性。本地节点访问走直连内存控制器，延迟低；跨节点访问必须经 QPI/UPI 互连总线，路径变长、协议开销增加，导致延迟成倍上升——这不是软件问题，而是硬件拓扑决定的性能边界。
NUMA 节点间延迟差异有多明显
实测数据显示：本地内存访问延迟约 10 ns，而跨一个节点升至 16–22 ns，跨两个节点可达 28–37 ns。换算为相对增幅，跨节点延迟比本地高 60%–180%。在高频读写场景（如数据库缓冲区、实时消息队列）中，这种差异会直接转化为吞吐下降与尾延迟飙升。
关键看 node distances 输出，例如：
node 0: 10 12 35 37
node 1: 12 10 37 40
同一行数字代表 node 0 到各节点（含自身）的距离值，数值越小越快。可见 node 0 → node 2 距离为 35，是本地（10）的 3.5 倍。
变量内存为何会落到远端节点
默认情况下，Linux 内存分配策略（localalloc）优先在当前 CPU 所属节点分配内存。但以下情况会导致变量实际落在远端：
- 进程启动时运行在 node 0，但后续被调度到 node 2 的 CPU 上执行，而堆/全局变量仍驻留在 node 0 内存中
- 多线程程序未显式绑定线程与 NUMA 节点，OpenMP 或 std::thread 创建的线程随机分布在不同 CPU，却共用同一块初始分配的内存
- 内存不足时触发跨节点分配或 swap，尤其当某节点 free memory 不足而其他节点仍有空闲时
如何让变量内存靠近使用它的 CPU
核心思路是“就近分配 + 就近执行”，需同时约束 CPU 亲和性与内存绑定策略：
- 启动服务时用 numactl --cpunodebind=0 --membind=0 强制限定在单一节点，适用于 Redis、MySQL 等单实例高吞吐服务
- 对多线程应用，在每个线程创建后立即调用 pthread_setaffinity_np 绑定 CPU，并用 numa_alloc_onnode 或 numa_set_preferred 分配线程专属内存池
- 避免混用策略：不要一边用
--membind=0，一边在代码里调用numa_set_interleave_mask，否则行为不可控 - 检查网卡 NUMA 归属（
cat /sys/class/net/eth0/device/numa_node），若应用处理网络数据，应确保线程与网卡位于同一节点
快速验证是否已改善
运行中观察 numastat -p
- numa_hit 占比应 >95%，说明绝大多数内存访问命中本地
- numa_miss 持续高于 5% 是明确信号，表示仍有大量被迫跨节点分配
- other_node 在 numastat -c 输出中占比超过 20%，说明进程正频繁访问远端内存
再配合 pidstat -t -p 确认线程是否稳定驻留，避免因调度漂移导致本地内存失效。
