Linux服务器NUMA架构性能调优实战：CPU亲和性与内存分配优化方案

NUMA（Non-Uniform Memory Access）架构是现代多路服务器的物理现实。CPU访问本地内存节点的延迟约80-100ns，跨节点访问延迟增加50%-100%。数据库、消息队列、AI推理等高并发服务对内存延迟敏感，忽略NUMA架构进行服务器运维会导致性能不可预期的下降。通过CPU亲和性绑定和NUMA内存分配策略，可以将关键服务的延迟降低15%-30%。

NUMA架构拓扑探测与性能影响量化

调优的前提是掌握服务器的NUMA拓扑。lscpu命令输出NUMA节点数量和CPU分布，numactl –hardware给出完整的节点拓扑和距离矩阵：

# 查看NUMA拓扑
numactl --hardware
# 输出示例（双路Xeon Platinum 8468Y+，每路48核）
# available: 2 nodes (0-1)
# node 0 cpus: 0 1 2 ... 47
# node 1 cpus: 48 49 50 ... 95
# node 0 size: 128944 MB
# node 1 size: 128980 MB
# node distances:
# node   0   1
#   0:  10  21
#   1:  21  10

距离矩阵中，本地访问距离为10，跨节点距离为21，意味着跨节点内存访问延迟约为本地的2.1倍。用numademo可以对不同访问模式进行基准测试：

# 测试本地访问 vs 跨节点访问的延迟
numademo -t 1000  # 1000MB数据集测试

# 使用perf测量内存访问延迟
perf mem -e load latency_record -p <PID> -- sleep 10

实测数据参考：某Redis实例运行在node 0 CPU上，数据存储在node 1内存中，GET操作P99延迟从0.3ms升至0.52ms，QPS下降约22%。将数据迁移至本地节点后恢复正常。

CPU亲和性绑定：taskset与cgroups实践

CPU亲和性（CPU Affinity）将进程绑定到特定NUMA节点的CPU核心，减少跨节点内存访问。taskset适合临时绑定，cgroups适合持久化管理。

# 查看进程当前CPU亲和性
taskset -cp <PID>

# 将进程绑定到NUMA node 0的CPU核心（0-47）
taskset -cp 0-47 <PID>

# 使用十六进制掩码绑定到特定核心
taskset -p 0x0000000F <PID>  # 绑定到CPU 0-3

对于多线程服务，更推荐使用numactl启动时绑定内存节点：

# 将进程的内存分配限制在NUMA node 0
numactl --cpunodebind=0 --membind=0 /usr/local/bin/redis-server /etc/redis/redis.conf

# --cpunodebind: CPU绑定到指定节点
# --membind: 内存分配限制在指定节点
# --preferred: 优先从指定节点分配，不足时允许跨节点

systemd服务可以通过Service配置实现NUMA绑定，避免手动执行命令：

# /etc/systemd/system/mysqld.service.d/numa.conf
[Service]
NUMAPolicy=bind
NUMAAffinity=0
CPUAffinity=0-47

执行 systemctl daemon-reload 后重启服务生效。对于KVM虚拟机，通过virsh vcpupin和virsh numatune实现Guest OS的NUMA绑定：

# 虚拟机vCPU绑定到物理CPU
virsh vcpupin vm-web 0 0-11
virsh vcpupin vm-web 1 12-23

# 虚拟机内存绑定到NUMA node
virsh numatune vm-web --mode bind --nodeset 0

NUMA Balancing机制评估与关闭策略

Linux内核默认启用NUMA Balancing（numad），周期性地将进程迁移到其内存所在的NUMA节点，以减少跨节点访问。这个机制对于计算密集型单一进程有益，但对数据库和缓存服务可能造成损害——迁移过程中的TLB刷新和内存拷贝会导致服务抖动。

# 查看NUMA Balancing状态
cat /proc/sys/kernel/numa_balancing
# 1=启用, 0=禁用

# 临时关闭
echo 0 > /proc/sys/kernel/numa_balancing

# 永久关闭
echo "kernel.numa_balancing = 0" >> /etc/sysctl.d/99-numa.conf
sysctl -p /etc/sysctl.d/99-numa.conf

关闭NUMA Balancing的决策依据：监控系统中的numa_hint_misses和numa_hint_faults指标。如果numa_hint_misses/numa_hint_faults比例持续高于30%，说明自动迁移产生的开销大于收益，建议关闭并手动配置绑定策略。

# 监控NUMA balancing统计
grep . /sys/kernel/debug/sched/numa_balancing/statistics 2>/dev/null
# 或使用perf
perf stat -e sched:numa_hint_faults,sched:numa_hint_faults_local,sched:numa_hint_misses -p <PID> sleep 30

内存分配策略：Transparent Huge Pages与NUMA交互

透明大页（THP）减少TLB缺失，但对NUMA架构有适配问题。THP的内存分配在NUMA节点间的分布不一定与进程的CPU绑定一致，可能导致大页来自远程节点。对于PostgreSQL、Oracle等大内存数据库，建议显式配置大页并绑定NUMA节点：

# 分配NUMA节点级大页
# 在node 0上分配512个2MB大页（共1GB）
echo 512 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
# 在node 1上分配512个2MB大页
echo 512 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

# 配置数据库使用大页
# PostgreSQL: postgresql.conf中设置
# huge_pages = on
# huge_page_size = 2048

对于Java应用（如Elasticsearch），JVM的NUMA感知分配通过-XX:+UseNUMA启用。该参数使JVM的G1堆区域按NUMA节点分布，但需要注意线程与块的对齐——线程访问跨节点的堆区域会引入额外延迟。建议配合-XX:+AlwaysPreTouch在启动时预触所有内存页，确保物理分配与NUMA节点一致。

NUMA性能监控体系搭建与瓶颈定位

系统级NUMA性能监控依赖numastat和perf两个核心工具。numastat按节点展示内存分配情况，关注跨节点内存占比：

# 实时查看各NUMA节点的内存统计
numastat -p <PID>
# 输出示例：
# Per-node process memory usage (in MBs)
#           Node 0 Node 1 Total
# ------   ------- ------ -----
# Huge      2048    0   2048
* Heap      8192  5120  13312
* Stack       12     8     20
* ------- ------- ------ -----
* Total    10252  5128  15380

# 查看系统级NUMA统计
numastat
# 重点关注 Other system memory 和 Numa_Hit / Numa_Miss 比例

Numa_Miss占比超过15%时需要排查。结合perf c2c工具分析缓存行争用和跨节点访问模式：

# 采集Cache-to-Cache传输数据
perf c2c record -p <PID> -- sleep 30
perf c2c report

perf c2c报告中的HITM（Hit Modified）统计直接反映跨CPU缓存行的写争用。如果节点间HITM占比高，说明存在频繁的跨节点数据共享，考虑调整数据结构布局或使用每节点独立数据副本（per-NUMA-node sharding）来消除跨节点写共享。