服务器NUMA架构性能调优实战：内存亲和性与线程绑定策略

NUMA架构对服务器性能的影响机制

现代多路服务器普遍采用NUMA（Non-Uniform Memory Access）架构，每个CPU插槽拥有本地内存控制器和对应的内存通道。当进程访问本地内存时延迟最低，跨NUMA节点访问远端内存则会产生额外的QPI/UPI互连延迟，典型差异在30%~60%之间。在高并发数据库、虚拟化和容器化场景中，NUMA感知调优直接决定了服务器的实际吞吐能力。

忽略NUMA架构的后果是：本应绑定在Node 0的进程被调度到Node 1执行，所有内存访问都变成跨节点操作，内存带宽减半、延迟倍增。这种“NUMA不友好”的部署方式，在双路服务器上可能导致20%~40%的性能损失。

NUMA拓扑探测与资源盘点

调优的第一步是搞清楚服务器的NUMA拓扑结构。Linux提供了numactl和lstopo两个核心工具：

# 查看NUMA拓扑
numactl --hardware
# 输出示例（双路EPYC 9654）：
# available: 2 nodes (0-1)
# node 0 cpus: 0 1 2 ... 47
# node 0 size: 245760 MB
# node 1 cpus: 48 49 50 ... 95
# node 1 size: 245760 MB

# 可视化拓扑
lstopo-no-graphics
# 显示CPU、Cache、NUMA节点的完整层级关系

关键指标包括：NUMA节点数量、每个节点的CPU核心范围、本地内存容量、节点间互连带宽。记录这些信息后才能制定精确的绑定策略。

进程级内存亲和性配置

numactl是配置进程NUMA策略的主力工具，支持四种内存分配策略：

–localalloc：优先分配本节点内存，不足时回退到其他节点。适合单节点即可满足内存需求的场景。

–preferred=node：优先从指定节点分配，不足时允许跨节点。适合内存需求可能超过单节点容量的场景。

–membind=nodes：严格限定只从指定节点分配，内存不足时触发OOM而非跨节点。适合对延迟敏感的关键进程。

–interleave=all：交错分配所有节点内存，适合对带宽需求高于延迟需求的场景。

# Redis绑定到Node 0，严格使用本地内存
numactl --cpunodebind=0 --membind=0 redis-server /etc/redis/redis.conf

# MySQL优先使用Node 1内存（允许回退）
numactl --cpunodebind=1 --preferred=1 mysqld --defaults-file=/etc/mysql/my.cnf

# Java应用交错分配（大堆场景）
numactl --interleave=all java -Xms32g -Xmx32g -jar app.jar

线程绑定与CPU亲和性优化

除了内存亲和性，线程的CPU绑定同样关键。操作系统默认的CFS调度器会在所有可用核心间迁移线程，导致缓存失效和跨节点访问。通过taskset或cgroups实现CPU亲和性绑定：

# 将Nginx worker绑定到Node 0的核心0-7
taskset -c 0-7 nginx

# 使用cgroups v2设置CPU亲和性
mkdir -p /sys/fs/cgroup/nginx
echo "0-7" > /sys/fs/cgroup/nginx/cpuset.cpus
echo "0" > /sys/fs/cgroup/nginx/cpuset.mems

对于数据库这类多线程应用，推荐将每个NUMA节点视为独立实例运行，避免跨节点线程同步：

# MySQL多实例方案：每个NUMA节点跑一个实例
# 实例1（Node 0）
numactl --cpunodebind=0 --membind=0 \
  mysqld --port=3306 --datadir=/data/node0 \
  --innodb-buffer-pool-instances=8

# 实例2（Node 1）
numactl --cpunodebind=1 --membind=1 \
  mysqld --port=3307 --datadir=/data/node1 \
  --innodb-buffer-pool-instances=8

Kubernetes环境下的NUMA感知调度

在容器化部署中，默认的kubelet调度完全忽略NUMA边界。CPU Manager的static策略和Memory Manager的静态策略提供了NUMA感知能力，需要在kubelet配置中显式启用：

# /var/lib/kubelet/config.yaml
cpuManagerPolicy: static
memoryManagerPolicy: Static
topologyManagerPolicy: best-effort  # 或 restricted、single-numa-node
reservedSystemCPUs: 0-1  # 系统保留核心
reservedMemory: "4Gi"

topologyManagerPolicy的三个级别：

– best-effort：尽量满足NUMA亲和性，不满足时仍可调度
– restricted：必须满足NUMA亲和性，不满足时拒绝调度
– single-numa-node：所有资源必须在同一NUMA节点，适用于对延迟极度敏感的工作负载

NUMA调优效果验证方法

调优前后需要量化验证，避免“感觉变快了”的主观判断：

1. 内存访问延迟测量

# 使用numactl测量跨节点延迟
numactl --cpunodebind=0 --membind=1 latency_test  # 跨节点
numactl --cpunodebind=0 --membind=0 latency_test  # 本地
# 对比两者差异，正常跨节点延迟约为本地的1.5-2倍

2. 实际业务基准测试

# MySQL sysbench对比
# 调优前
sysbench oltp_read_write --threads=64 --tables=32 run
# 调优后（绑定NUMA节点后重复测试）
# 关注TPS和P99延迟的变化

3. 运行时NUMA统计

# 查看进程的跨节点内存访问次数
cat /proc/$(pgrep -x mysqld)/numa_stat
# 关注 num_hit（本地命中）和 num_miss（跨节点访问）的比例
# 理想状态：num_miss / num_hit < 5%

NUMA调优不是一次性的配置动作，而是需要结合负载特征持续迭代的工程实践。服务器硬件升级、业务流量模型变化、容器编排策略调整都可能使之前的优化失效，定期审查NUMA统计指标是保持性能水平的关键。