--membind仅约束后续malloc/new等新内存分配，不影响已加载代码段和栈；--cpunodebind只限制线程运行CPU节点，不自动迁移内存，二者需配合使用以防跨节点访问。
numactl --membind 和 --cpunodebind 的实际作用差异
很多人以为 numactl --membind 就是“把进程内存全锁在某个 NUMA 节点”，其实不是：它只影响进程后续新分配的内存（如 malloc、mmap(MAP_ANONYMOUS)），对已加载的代码段、共享库、stack 初始化内存无效。而 --cpunodebind 确实会限制线程只能在指定节点的 CPU 上运行，但不会自动拉内存过去——如果线程在 node1 运行却访问 node0 的内存，就是跨节点访存，延迟翻倍。
高并发服务（比如用 std::thread 或 epoll + 多线程 reactor）必须同时约束 CPU 和内存，否则线程绑对了，堆内存还在远端节点，性能反而更差。
-
--cpunodebind=0：线程调度器只把该进程的线程放到 node 0 的 CPU 上 -
--membind=0：所有后续new、malloc、std::vector::resize分配的内存都来自 node 0 的本地内存 - 若只用
--cpunodebind不加--membind，线程可能在 node 0 执行，但 new 出来的对象内存仍在默认节点（通常是 node 0，但受/proc/sys/kernel/numa_balancing和启动时系统状态影响）
启动 C++ 进程时绑定的正确命令写法
不要用 numactl --cpunodebind=0 --membind=0 ./myserver 这种写法——它只约束主进程，子线程（如 std::thread 创建的）默认继承父进程的 NUMA 策略，但实际效果不稳定，尤其在调用 fork() 或使用线程池时容易失效。
更可靠的方式是：用 numactl 启动，并确保 C++ 程序内部不主动调用 set_mempolicy() 或 mbind() 覆盖它；同时避免在程序里调用 pthread_attr_setaffinity_np() 却不配套做内存绑定。
立即学习“C++免费学习笔记（深入）”；
- 推荐启动命令：
numactl --cpunodebind=0 --membind=0 --preferred=0 ./myserver -c 8（--preferred=0是 fallback 策略，当 node 0 内存不足时仍优先尝试分配到 node 0） - 验证是否生效：
numastat -p $(pgrep myserver)查看Numa_Hit是否集中在目标节点，Numa_Miss接近 0 - 注意：如果程序自己调用了
mbind()或set_mempolicy(MPOL_BIND)，会覆盖numactl的初始策略，需检查代码中是否有这类调用
std::thread 创建后如何保持 NUMA 局部性
std::thread 对象本身不继承父线程的内存分配策略，但它继承父进程的 membind 设置——前提是没被中间层（如 glibc 的 malloc 实现、jemalloc 配置）干扰。glibc 默认的 malloc 在多线程下会为每个线程维护独立的 arena，而 arena 的内存来源取决于首次分配时的 NUMA 策略。所以第一个 new 发生在线程刚创建后，此时 numactl 的 --membind 仍然有效。
- 安全做法：在线程函数入口立即分配一块小内存（如
new char[1]），强制触发 arena 初始化，确保后续分配走本地节点 - 避免使用
std::vector::reserve()在主线程预分配大量内存再传给子线程——那块内存属于主线程当时的 NUMA 节点，子线程访问它仍是远程访问 - 若用 jemalloc，需确认编译时启用了
--enable-numa，并设置环境变量MALLOC_CONF="narenas:1,metadata_thp:auto"，否则它可能忽略numactl策略
常见误判：numastat 显示 Numa_Miss 高却不一定是绑定失败
numastat -p PID 中的 Numa_Miss 高，不一定代表 numactl 没起作用。它可能源于：
- 程序加载的共享库（如
libstdc++.so）内存页在启动时已分配在其他节点，且无法迁移（mmap 的 MAP_PRIVATE 页不可move_pages()） - 内核模块或驱动分配的内存（如 DPDK 的 hugepage 内存需单独用
numactl --membind=0 --hugepages=...绑定） -
/proc/sys/vm/zone_reclaim_mode开启时，内核可能主动从远端节点回收内存，导致统计上出现 Miss - 某些 STL 容器（如
std::string的 small string optimization）不触发堆分配，因此不走--membind策略，但它们本身很小，影响可忽略
真正要盯的是 Numa_Hit 占总分配的比例，以及业务核心对象（如连接结构体、buffer pool）的 malloc 是否稳定落在目标节点——这需要用 perf record -e 'kmem:mm_page_alloc' -p PID 结合 numactl --hardware 输出交叉验证。
