在由多路服务器构成的集群环境中，NUMA（Non-Uniform Memory Access）架构几乎是主流硬件的默认形态。每个物理 CPU 插槽及其直连的内存组成一个 NUMA 节点，节点内部访问延迟低，跨节点访问则需经过 QPI 或 UPI 等互连总线，延迟和带宽都明显劣化。如果集群调度系统忽视这种拓扑差异，把计算任务随意分配到不同节点的 CPU 和内存上，就会引发严重的性能抖动。理解并正确配置 NUMA 亲和性，是集群性能调优中不可跳过的一环。
NUMA 架构下的访存延迟差异与性能原理
现代服务器通常配备两颗或更多 CPU，每颗 CPU 集成内存控制器，负责一部分 DIMM 插槽。操作系统通过 ACPI 表识别这些资源并划分出多个 NUMA 节点。以双路服务器为例，节点 0 的 CPU 访问本地内存可能只需 80 纳秒，而访问节点 1 的内存可能超过 160 纳秒。这种非一致的内存访问延迟，在内存频繁读写的场景中会被成倍放大。
当集群中的某个服务线程被调度到节点 0 的 CPU，但其使用的内存页却分配在节点 1 时，每次访存都要穿越互连通道。更糟糕的是，若线程在运行时被操作系统迁移到节点 1 的 CPU，原本在节点 0 缓存中的数据失效，新 CPU 的缓存需重新 Warm up。对于延迟敏感型应用，如分布式数据库、消息队列，这种跨节点抖动会直接推高 P99 延迟。
通过 numactl --hardware 可以直观看到节点距离矩阵。距离值越大代表访问开销越高。集群运维人员应首先采集每台物理机的 NUMA 拓扑，作为后续亲和性绑定的基础。忽视这一层硬件事实，仅依靠默认调度，往往使机器空有强大算力却无法发挥。
# 查看 NUMA 节点拓扑与 CPU 分布 numactl --hardware # 典型输出示例（转义后仅供阅读，实际命令无转义） # available: 2 nodes (0-1) # node 0 cpus: 0 1 2 3 4 5 6 7 # node 0 size: 32768 MB # node 1 cpus: 8 9 10 11 12 13 14 15 # node 1 size: 32768 MB
物理机集群中 NUMA 亲和性的配置方法
在裸金属或传统虚拟机集群里，最直接的控制工具是 numactl。它允许在启动进程时指定 CPU 绑定范围与内存分配策略。常用的策略包括 --cpunodebind 限定 CPU 所在节点，--membind 限定内存来自哪些节点，以及 --interleave 做交错分配。对于追求稳定低延迟的服务，建议采用严格绑定，避免跨节点。
例如，将某内存数据库实例绑定到节点 0 的 CPU 与本地内存，命令如下。这样该进程的所有线程都不会被调度到其他节点，分配的内存也始终在本地，彻底消除远端访存。若服务需要跨节点扩展，则应启动多个实例，每个实例绑定独立节点，而非让单一进程跨节点运行。
除了进程级绑定，内核参数也可辅助优化。如设置 vm.zone_reclaim_mode 为 1，可让内核更倾向于回收本地节点内存而非从远端分配，缓解本地内存压力。但这一参数需结合真实负载测试，不当设置反而会引起回收开销。因此物理机集群的 NUMA 配置应以实测吞吐和延迟为最终判据。
# 将服务严格绑定到 NUMA 节点 0 numactl --cpunodebind=0 --membind=0 /opt/app/bin/server --port 8080 # 查看某进程当前的 NUMA 策略 numactl -p $(pidof server)
容器与 Kubernetes 集群的拓扑管理配置
在云原生集群中，Pod 默认由 kube-scheduler 按 CPU 和内存总量调度，不感知 NUMA 节点边界。若节点开启超线程且跨 NUMA 分配，容器内的进程仍会遭受性能损失。Kubernetes 从 1.18 起提供拓扑管理器（Topology Manager），与 CPU 管理器、设备管理器协同，实现 NUMA 对齐。
启用方式是在 kubelet 配置中设置 topologyManagerPolicy 为 single-numa-node 或 restricted。前者保证 Pod 的所有算力与设备落入同一 NUMA 节点，后者在无法对齐时拒绝调度。配合 cpuset 静态分配，Pod 中的容器将获得独占的 CPU 核与本地内存。以下为 kubelet 配置片段示例。
对于离线混部或弹性集群，还可借助 NUMA 感知的调度插件，在调度层提前过滤掉不满足亲和性的节点。同时，在容器镜像启动脚本中使用 numactl 作为入口命令，也能在调度器未完全隔离时提供最后一道保障。只有硬件拓扑、操作系统、编排系统三层协同，集群 NUMA 亲和性才能真正转化为性能收益。
# kubelet 配置示例（部分） apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration cpuManagerPolicy: static topologyManagerPolicy: single-numa-node reservedSystemCPUs: "0,8"
综上所述，集群 NUMA 亲和性并非高级黑魔法，而是基于硬件事实的基础调优。从识别拓扑、进程绑定到编排系统策略，每一步都需结合业务特征反复验证。忽视它，集群规模再大也难逃隐性性能墙；用得好，同等硬件即可挤出可观的吞吐空间。