必须先执行numactl --hardware确认是否有多个NUMA节点（如available: 2 nodes (0-1)），若仅显示available: 1 node，则为UMA或NUMA被禁用，此时--membind无效且可能引入额外开销。
确认系统是否真有 NUMA 节点
没 NUMA 就别用 numactl --membind，否则不仅无效，还可能引入额外开销。必须先执行：
numactl --hardware
看输出里有没有类似 available: 2 nodes (0-1)。如果只显示 available: 1 node，说明是 UMA 架构（或 BIOS 关了 NUMA / 开了 Node Interleaving），此时 --membind 不起作用。
常见误判点：
-
lscpu显示多个 CPU socket ≠ 有 NUMA；得看numactl --hardware的node X cpus:行 - 虚拟机默认不暴露 NUMA 拓扑，即使宿主机是双路 Xeon，
numactl --hardware也可能只报 1 个 node - BIOS 中 “Node Interleaving” 或 “Memory Interleaving” 必须关闭，否则内存被逻辑合并，看不到真实节点
只绑内存节点：--membind vs --preferred
--membind=0 是硬绑定：进程只能从节点 0 分配内存，若该节点内存不足，malloc() 或 mmap() 直接失败（返回 ENOMEM）。
--preferred=0 是软策略：优先从节点 0 分配，不够时自动 fallback 到其他节点——适合对稳定性要求高、但性能敏感度中等的场景。
两者都不能单独用在生产服务里，原因很直接：
- 只绑内存不绑 CPU → 进程可能在 node 1 的 CPU 上跑，却强制从 node 0 分配内存 → 跨节点访问，延迟翻倍
- 只绑 CPU 不绑内存 → 进程在 node 0 的 CPU 上跑，但内存仍按默认策略分配（可能落在 node 1）→ 同样跨节点
正确绑定：--cpunodebind 和 --membind 必须配对
真正有效的命令长这样：
numactl --cpunodebind=0 --membind=0 ./your_program
这表示：只允许进程在 NUMA 节点 0 的所有 CPU 上运行（比如 node0 cpus: 0,2,4,6...），且所有内存都必须从节点 0 分配。
关键细节：
-
--cpunodebind=0≠--physcpubind=0,1,2,3：后者按物理 CPU 编号指定，不管归属哪个节点；前者按节点维度，自动包含该节点全部 CPU - 如果 CPU 0 属于 node 0，CPU 1 属于 node 1，用
--physcpubind=0,1就会跨节点调度，反而更慢 - 节点编号不能写错，比如只有 node 0 和 1，写
--membind=2会导致命令静默失败（进程照常启动，但不生效）
验证是否真的绑成功了
启动后别信命令没报错就完事。用以下方式确认：
- 查进程当前 NUMA 策略：
numastat -p <pid></pid>，看Numa_Hit是否集中在目标节点 - 查 CPU 亲和性：
taskset -cp <pid></pid>，确认实际运行的 CPU 是否全属于目标节点（对照numactl --hardware输出） - 观察
/proc/<pid>/status</pid>中的MMUPageSize和NUMAPolicy字段（需内核支持）
最容易被忽略的是：绑定后程序内存增长过快，导致目标节点内存耗尽，--membind 会让它直接 OOM，而 --preferred 会悄悄跨节点——这时你得看 numastat 的 Numa_Miss 和 Numa_Foreign 才知道是不是“表面绑定、实际失效”。
