numactl --hardware是确认numa开启及存在跨节点访问的首要命令，输出含available: n nodes（n ≥ 2）即表示启用；若显示no numa configuration found，则bios或内核禁用了numa。
怎么确认系统开启了NUMA且存在跨节点访问
不查拓扑就谈优化，等于蒙眼调参。先运行 numactl --hardware，看输出里有没有 available: N nodes（N ≥ 2）；如果显示 No NUMA configuration found，说明BIOS里关了NUMA或内核启动加了 numa=off。接着用 cat /sys/class/net/eth0/device/numa_node 查网卡归属节点——很多延迟问题其实始于网卡在node 0、而worker线程跑在node 1。
怎么量化跨节点内存访问延迟差异
别只看 perf stat -e cycles 的 wall time，它受调度抖动干扰太大。真实延迟要靠 cache line 级别对比：
-
taskset -c 0 numactl --membind=0 --cpunodebind=0 dd if=/dev/zero of=/tmp/test bs=1M count=100：本地 node 访问 -
taskset -c 0 numactl --membind=1 --cpunodebind=0 dd if=/dev/zero of=/tmp/test bs=1M count=100：强制跨 node 访问（CPU 在 node 0，内存绑到 node 1） - 用
perf stat -e cycles,instructions,cache-misses包裹上述命令，重点看cycles / cacheline比值 —— 跨节点通常比本地高 1.5–2 倍以上
怎么定位具体进程的跨节点访问比例
单看全局指标没用，得落到 PID 上。两个命令必须配合着看：
-
numastat -p $PID：看Heap和Stack列是否集中在某 node；如果 node 0 占 95%，node 1 占 5%，基本健康 -
numastat -c $PID：算numa_foreign / (numa_hit + numa_foreign)，>5% 就该警惕，>15% 基本确认错位严重 - 注意：子进程默认不继承
numactl绑定，numastat -c显示异常时，先确认是不是子进程没重绑
为什么绑了 --cpunodebind 还有跨节点访问
这是最常踩的坑：--cpunodebind=0 只限制 CPU 调度范围，**完全不管内存分配**。进程仍可能从 node 1 malloc 内存，导致大量 numa_miss。真正起效的组合只有两种：
-
--cpunodebind=0 --membind=0：严格同节点，但 node 0 内存不足时会直接malloc失败 -
--cpunodebind=0 --preferred=0：倾向 node 0，fallback 安全，适合生产环境 - 大页内存必须提前在目标 node 预留：
echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages，写/proc/sys/vm/nr_hugepages是无效的
numastat -p $PID 的实时分布，以及 taskset -p $PID 输出的 CPU mask 是否和 numactl --hardware 中 node 0 的 CPU 列表一致。跨节点延迟不是玄学，是可测、可定位、可收敛的具体数字。
