NUMA 与内存访问差异
多路服务器上每个 CPU 有自己的本地内存，跨节点访问内存的延迟明显更高。Redis 是单进程、大内存的负载：内存分散在多个节点时，一部分访问要跨节点完成，表现为延迟抖动。是否绑定不能凭感觉——先看拓扑与进程的内存分布，再评估收益与风险，云主机与容器里的收益尤其不确定。
基本信息
| 现象 | 跨 NUMA 节点访问内存延迟更高，表现为抖动 |
|---|---|
| 查看命令 | numactl --hardware、numastat、numastat -p 进程 |
| 自动机制 | 内核自动 NUMA 平衡，开关在 /proc/sys/kernel/numa_balancing |
| 常见手段 | 按节点绑定 CPU 与内存、多实例分散部署 |
| 相关项 | 透明大页会独立放大延迟抖动 |
| 前提 | 先观测数据，再决定是否绑定 |
典型使用场景
- 延迟抖动排查：确认内存是否分散、跨节点访问是否明显
- 规格评估：单实例内存超过单节点容量时预估跨节点影响
- 部署规划：多实例时把实例与内存分别落到不同节点
- 新机器验收：先看拓扑与各节点内存分布，再定部署密度
- 内核参数核对：确认自动平衡与透明大页的实际状态
最小示例
最小示例
numactl --hardware # 节点数与各节点内存大小
numastat # 各节点内存命中与未命中统计
numastat -p <redis_pid> # 进程的内存跨节点分布
cat /proc/sys/kernel/numa_balancing # 自动 NUMA 平衡开关
cat /sys/kernel/mm/transparent_hugepage/enabled # 透明大页状态
lscpu | grep -i numa # CPU 侧 NUMA 信息观察与手段
| 观察项 | 含义 | 处理方向 |
|---|---|---|
| 节点数与内存分布 | 每个节点可用的内存 | 单节点放不下实例内存就不要强行绑定 |
| 跨节点未命中计数 | 跨节点访问的规模 | 计数高说明内存分散访问明显 |
| 进程内存分布 | 实例内存落在哪些节点 | 分散时评估绑定收益 |
| 自动平衡状态 | 内核是否自动搬移内存页 | 开启是常态，关闭后需要手动规划 |
| 透明大页状态 | 是否启用 THP | 低延迟场景建议关闭 |
NUMA 调优收益高度依赖机器与负载：绑定 CPU 与内存都可能带来新的资源不均，容器与虚拟化环境下看到的拓扑是宿主映射的结果。
透明大页是延迟抖动的独立来源，排查抖动时把它的状态一并核对，不要只盯内存分布。