跨NUMA节点分配内存导致性能暴跌，因远程访问延迟达200–300ns（本地仅70–100ns）且带宽降至40%–60%；须同步绑定线程到CPU节点并用numa_alloc_onnode在同节点分配内存，缺一不可。

为什么跨NUMA节点分配内存会导致性能暴跌

在双路或四路服务器上，CPU访问本地NUMA节点内存的延迟通常为70–100ns，而访问远端节点内存可能高达200–300ns。更致命的是带宽下降——远程访问带宽常只有本地的40%–60%。如果你用new或malloc分配内存，操作系统默认从当前线程所在节点的“首选内存池”分配；但若该线程随后被调度到另一NUMA节点执行（比如未设亲和性），它就会持续访问远端内存，形成隐蔽的性能黑洞。

如何让线程与内存同节点共存

必须同步控制两件事：线程在哪跑、内存从哪分。缺一不可。

• 先用sched_setaffinity或std::this_thread::set_affinity（C++26）将线程绑定到某物理Socket上的核心（例如cpu_id 0–15属于Node 0）
• 再调用numa_alloc_onnode(size_t size, int node)在对应节点分配内存，而非malloc
• 若使用std::vector等容器，需自定义Allocator，内部调用numa_alloc_onnode并传入预知的node ID（可通过numa_node_of_cpu(cpu_id)反查）

OpenMP场景下容易忽略的陷阱

OMP_NUM_THREADS=32不等于性能最优——尤其当系统有2个NUMA节点、每节点16核时，盲目启用32线程会触发跨节点任务调度和内存争抢。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• 用OMP_PLACES="{0}:16,{1}:16"显式划分两个节点各16个逻辑位置
• 配合OMP_PROC_BIND=close，确保线程优先填满一个NUMA节点再扩展到下一个
• 禁用超线程干扰：lscpu | grep "Thread(s) per core"确认是否为2，若业务是计算密集型，应设OMP_NUM_THREADS=16并只用物理核心

验证是否真正生效的三步检查法

光写代码不验证，等于没做优化。运行后立刻检查：

• 用numastat -p 看numa_hit是否远高于numa_foreign（理想比值 > 95:5）
• 用taskset -cp 确认线程实际运行在预期CPU上
• 在分配内存后，调用numa_move_pages(0, 1, &addr, &node, &status, 0)主动迁移页面到目标节点（避免首次访问触发缺页中断时误选远端内存）

最易被跳过的环节是：线程绑定了核心，却忘了让内存也落在同一节点——这两者必须成对出现，否则所有亲和性设置都白费。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！