确认NUMA跨节点访问瓶颈需结合numastat（查numa_hit/numa_miss比值及numa_foreign指向）与perf（监控mem_load_retired.l3_miss等远程访问事件），而非仅依赖CPU使用率或整体延迟。
怎么确认性能瓶颈真是NUMA跨节点访问引起的
光看 CPU 使用率或整体延迟没用，得抓内存访问的物理位置证据。先用 numastat 查进程各 NUMA 节点上的内存分配分布，重点关注 numa_hit 和 numa_miss 的比值——如果某线程在 node 0 上运行，但 numa_miss 高、numa_foreign 指向 node 1，这就是跨节点访问的铁证。再配合 perf record -e mem-loads,mem-stores -a -- sleep 5 + perf script 看 load/store 指令是否频繁触发远程内存访问事件（如 mem_load_retired.l3_miss 在跨节点时显著升高）。别只信 top 或 htop，它们不反映内存拓扑。
pthread_create 后线程默认在哪跑？怎么绑定到指定 NUMA 节点
Linux 默认不保证线程和内存同节点，哪怕你用 numactl --membind=1 --cpunodebind=1 ./a.out 启动主进程，新创建的线程仍可能被调度到其他 CPU，且分配内存时仍可能 fallback 到本地 node 0。必须在线程函数入口处主动绑定：cpu_set_t cpuset + pthread_setaffinity_np 设定 CPU；再调用 set_mempolicy(MPOL_BIND, &node_mask, maxnode + 1) 锁定内存分配策略。注意：两个操作顺序不能反，否则内存可能已按默认策略分配完毕；也别依赖 numactl 一次启动就万事大吉。
std::vector 和 new 分配的内存为什么总在错误节点上
C++ 默认分配器不感知 NUMA，new 和 std::vector::resize 走的是 glibc 的 malloc，而它默认使用 MPOL_DEFAULT，即“优先本地节点，失败才 fallback”。问题在于：首次分配发生在哪个线程上下文，就倾向绑定那个节点的内存池。解决方案有三：
- 启动时用
mallopt(M_MMAP_THRESHOLD, 0)强制小对象也走 mmap，再配合mpol_set_memory主动迁移已分配页（慎用，开销大） - 换用 NUMA-aware 分配器，如
libnuma的numa_alloc_onnode+ 自定义分配器（需重载operator new） - 更稳妥的是预分配：主线程在目标 node 上用
numa_alloc_interleaved或numa_alloc_onnode分一大块内存，后续线程只在这块里做placement new
std::thread 构造时传参引发的隐式拷贝会破坏 NUMA 局部性
常见坑：std::thread t(func, my_big_struct) —— 这会把 my_big_struct 拷贝进线程私有栈，而拷贝动作本身发生在主线程所在的 NUMA 节点，新内存大概率分配在 node 0，即使线程绑到了 node 1。结果是：线程在 node 1 执行，却反复访问 node 0 上的拷贝数据。改法只有两个：
- 传指针或引用（确保原始对象已在目标 node 分配好）
- 用
std::move传右值，但前提是该类型支持移动且移动构造不触发新内存分配（比如内部用numa_alloc_onnode分配的 buffer）
std::thread 是语法糖就安全，它的参数传递机制对 NUMA 敏感度极高。立即学习“C++免费学习笔记（深入）”；
排查 NUMA 问题最耗时间的环节，往往不是定位，而是验证“改完之后真的变好了”——因为缓存预热、TLB 填充、内核调度抖动都会掩盖真实效果。务必用固定线程数、固定数据规模、关闭 CPU 频率调节（echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor），再跑至少 5 轮带标准差的 benchmark。
