分配1G大页时NUMA节点1的mlock调用返回缓慢问题求助

关键观察 #

从提供的trace日志可以得到以下确定信息：

• NUMA节点0和节点1的空闲1G大页数量均为20，大页总资源充足，排除资源不足导致的性能问题
• 绑定节点0执行mlock调用耗时仅0.205s，绑定节点1时相同操作耗时高达3.52s，性能差距超过17倍
• 两次操作的系统调用流程完全一致，排除业务代码逻辑差异导致的问题

根因分析 #

1. NUMA节点1物理内存碎片化，需要实时规整才能分配1G大页 #

1G大页要求连续的物理内存地址空间，如果节点1的空闲内存虽然总容量足够，但已经被零散分配的4K页、2M页占满，没有现成的连续1G物理段，内核在mlock触发实际内存分配时，需要先启动内存规整流程：回收可回收的文件页、匿名页，移动已分配的非大页内存整理出连续的1G空间，这个过程会产生秒级的耗时。而节点0的1G大页已经提前完成预分配，不需要规整，所以速度更快。

2. 节点1内核内存管理线程负载高，分配流程被阻塞 #

如果节点1上运行了其他高内存负载的进程，导致kswapd（内存回收线程）、kcompactd（内存规整线程）一直处于繁忙状态，大页分配请求会排队等待内核线程完成资源整理，也会出现额外的耗时。

3. 节点1大页预分配配置异常 #

如果仅在节点0配置了静态大页预分配，节点1的1G大页是运行时动态分配的，动态分配大页本身就比直接用预分配的大页慢很多，也会出现上述性能差距。

排查与解决建议 #

1. 执行以下命令确认两个节点的大页分配状态和碎片化程度：

grep -A 5 Huge /sys/devices/system/node/node0/meminfo
grep -A 5 Huge /sys/devices/system/node/node1/meminfo
cat /sys/devices/system/node/node1/compact/pages_moved

查看节点1是否有大页分配失败计数、内存规整的页面移动统计是否很高，确认是否存在碎片化问题。
2. 优先在系统启动时配置静态大页预分配，确保两个节点的1G大页都在内核初始化阶段预留，避免运行时分配开销，启动参数参考：

default_hugepagesz=1G hugepagesz=1G hugepages=20:0 hugepages=20:1

3. 若无法重启系统，可主动触发节点1的内存规整，提前整理出连续大页空间：

echo 1 > /sys/devices/system/node/node1/compact

内容的提问来源于stack exchange，提问作者Charles