Linux内存管理：NUMA架构下的性能调优实战

1. 为什么你的多核服务器跑不满性能？

最近在调试一台32核的数据库服务器时，遇到个奇怪现象：CPU使用率始终在60%左右徘徊，加更多并发连接也上不去。用perf工具分析后发现，超过30%的CPU时间都花在了内存访问上——这明显不正常。经过排查，最终发现是NUMA架构惹的祸。

现代服务器普遍采用NUMA（Non-Uniform Memory Access）架构，简单说就是每个CPU核心访问不同区域内存的速度不一样。比如一台双路服务器，CPU0访问自己插槽上的内存可能只要100ns，但访问CPU1插槽上的内存就要200ns。这种差异在普通应用中不明显，但对数据库、HPC这类内存密集型应用就是性能杀手。

我见过最夸张的案例是某个金融交易系统，仅仅因为进程跑在了"错误"的NUMA节点上，延迟直接翻倍。下面分享几个实战中总结的调优技巧。

2. NUMA基础：从硬件到Linux实现

2.1 硬件层面的NUMA拓扑

先看个真实服务器的NUMA拓扑（通过numactl --hardware查看）：

available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23 node 0 size: 31768 MB node 0 free: 12689 MB node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31 node 1 size: 32254 MB node 1 free: 18321 MB

这台服务器有两个NUMA节点（node 0和1），每个节点有16个逻辑CPU和约32GB内存。关键点在于：

• CPU核心分组：物理上属于同一插槽的CPU会被划分到同个NUMA节点
• 内存本地性：每个节点有自己"本地"的物理内存
• 访问代价：跨节点访问内存的延迟可能增加50%-100%

2.2 Linux的NUMA内存分配策略

Linux内核默认使用"本地优先"策略，但具体行为受以下参数影响：

# 查看当前策略 cat /proc/sys/vm/zone_reclaim_mode # 常用策略说明 0 - 关闭回收，优先从其他节点分配 1 - 开启回收，当本地内存不足时回收缓存 4 - 激进回收（可能引发性能抖动）

实际测试发现，对于MySQL这类长运行进程，设置为1（平衡模式）通常最稳定。而短期运行的批处理任务可能更适合0（跨节点分配）。

3. 实战调优：从工具到案例

3.1 必须掌握的NUMA诊断工具

numastat是最直接的监控工具：

# 每5秒刷新一次各节点内存统计 numastat -c 5 Per-node numastat stats (in MBs): Node 0 Node 1 Numa_Hit 124568.12 118743.45 Numa_Miss 832.41 1945.67 Numa_Foreign 1945.67 832.41

关键指标解读：

• Numa_Hit：本地内存访问量（越高越好）
• Numa_Miss：跨节点访问量（超过10%就需要优化）
• Numa_Foreign：其他节点访问本节点内存的次数

perf也能发现NUMA问题：

perf stat -e cycles,instructions,cache-misses,L1-dcache-load-misses,LLC-load-misses -p <PID>

如果发现LLC-load-misses（最后一级缓存未命中）特别高，很可能就是NUMA访存问题。

3.2 内存绑定实战技巧

对于关键应用，推荐用numactl显式绑定：

# 将MySQL绑定到node0，且只使用本地内存 numactl --cpunodebind=0 --membind=0 /usr/sbin/mysqld # 更灵活的策略：允许使用其他节点内存，但优先本地 numactl --cpunodebind=0 --preferred=0 /usr/sbin/mysqld

对于多进程应用（如Nginx），可以按worker绑定不同节点：

# 在nginx.conf中 worker_processes 4; worker_cpu_affinity 1000 0100 0010 0001; # 启动脚本中 numactl --cpunodebind=0 --membind=0 nginx -c /etc/nginx/nginx.conf

4. 高级技巧与避坑指南

4.1 大页内存的NUMA优化

使用透明大页（THP）时要注意NUMA问题：

# 查看THP状态 cat /sys/kernel/mm/transparent_hugepage/enabled # 建议对数据库关闭THP echo never > /sys/kernel/mm/transparent_hugepage/enabled

更好的做法是使用显式NUMA大页：

# 为每个节点预留1GB大页 echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages echo 1024 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages # 启动时绑定大页 numactl --membind=0 --huge ./memory_intensive_app

4.2 常见陷阱排查

陷阱1：内存泄漏误判某次我们发现node0内存耗尽，但node1还有大量空闲。以为是内存泄漏，实际是NUMA策略导致。解决方案：

# 临时平衡内存分配 echo 0 > /proc/sys/vm/zone_reclaim_mode # 永久修改（需测试稳定性） sysctl -w vm.zone_reclaim_mode=0

陷阱2：跨节点锁竞争有个Java应用在NUMA环境下性能下降50%，最终发现是同步锁频繁跨节点访问。通过-XX:+UseNUMA参数解决：

java -XX:+UseNUMA -Xms16g -Xmx16g -jar app.jar

陷阱3：虚拟机NUMA对齐在KVM虚拟化中，务必保证vCPU与NUMA节点对齐：

<!-- libvirt配置示例 --> <cpu mode='host-passthrough'> <numa> <cell id='0' cpus='0-7' memory='8388608'/> <cell id='1' cpus='8-15' memory='8388608'/> </numa> </cpu>

调优前后对比一个真实MySQL案例：

最后提醒：所有NUMA调优都要基于实际监控数据，盲目绑定可能适得其反。建议先用numastat和perf收集基线数据，再针对性调整。