当前位置:首页>Linux>连NUMA都没搞不懂,还敢说精通Linux内核?

连NUMA都没搞不懂,还敢说精通Linux内核?

  • 2026-10-11 07:53:43
连NUMA都没搞不懂,还敢说精通Linux内核?

很多人一说“精通 Linux”,结果一问 NUMA(Non-Uniform Memory Access,非统一内存访问架构)就开始沉默了。

这句话虽然有点“扎心”,但其实很真实。

因为现代 Linux 性能调优,尤其是:

  • 数据库(MySQL / Oracle / PostgreSQL)
  • Redis / Kafka
  • KVM / VMware 虚拟化
  • Kubernetes 高性能节点
  • AI 推理服务器
  • 大内存、高核数物理机(64核/128核+)

如果不理解 NUMA,本质上就是:

“CPU 在哪里跑、内存从哪里取、跨节点访问代价有多高”完全没概念。

这已经不是“高级优化”了,而是现代 Linux 架构基础。


一、NUMA 到底是什么?

传统早期服务器:

  • 所有 CPU 共享同一块内存
  • 访问延迟一致

这叫:

UMA(Uniform Memory Access)

后来 CPU 核数越来越多:

  • 32核
  • 64核
  • 128核
  • 多路 CPU

如果大家都抢同一块内存:

  • 总线爆炸
  • 延迟暴涨
  • 缓存同步灾难

于是出现:

NUMA(非统一内存访问)

核心思想:

每个 CPU Socket 拥有“本地内存”

CPU 访问:

  • 自己节点内存 → 快
  • 别的节点内存 → 慢

所以:

“内存有距离”

这就是 NUMA 最核心的一句话。


二、很多运维为什么性能调不明白?

因为他们只看:

tophtopvmstatiostat

但真正的问题是:

  • CPU0 在跑进程
  • 内存却分配在 NUMA Node1
  • 产生跨 NUMA 访问
  • QPI/UPI 总线被打爆
  • 延迟暴涨

结果:

  • CPU 利用率不高
  • 系统却卡
  • 数据库 TPS 上不去
  • Redis 延迟抖动
  • JVM GC 异常

然后开始:

  • 怀疑磁盘
  • 怀疑网络
  • 怀疑 JVM
  • 怀疑 Redis 参数

唯独没人看 NUMA。

这在生产环境里非常常见。


三、NUMA 的本质(必须真正理解)

假设:

CPU Socket0 <-> 内存0CPU Socket1 <-> 内存1

如果:

CPU0 访问 内存0

属于:

本地访问(local access)

延迟低。

但:

CPU0 访问 内存1

属于:

远程访问(remote access)

需要:

  • 跨 Socket
  • 走 UPI/QPI
  • Cache 同步

延迟可能高几十%。

所以:

NUMA 本质是:

“CPU 与内存亲和性问题”


四、Linux 内核到底怎么处理 NUMA?

Linux 内核里有:

  • NUMA Balancing
  • Zone reclaim
  • CPU Affinity
  • Memory Policy
  • cpuset
  • scheduler domains

内核调度器会尝试:

  • 让线程靠近内存
  • 让内存靠近 CPU
  • 减少 remote memory access

但:

自动 NUMA balancing 并不总是有效。

尤其:

  • Redis
  • Oracle
  • JVM
  • DPDK
  • 高并发数据库

很多时候需要手工绑定。


五、真正的高手会先看这些

1. NUMA 拓扑

numactl --hardware

或者:

lscpu

重点看:

  • NUMA node数量
  • CPU属于哪个 node
  • 内存属于哪个 node

2. 进程 NUMA 分布

numastat -p <pid>

这才是真正关键。

看:

  • local
  • remote

如果 remote 很高:

性能一定有损耗。


3. CPU 与内存绑定

例如:

numactl --cpunodebind=0 --membind=0 redis-server

意思:

  • CPU 只跑 node0
  • 内存也从 node0 分配

这才是真正低延迟。


六、为什么 Redis/Kafka/MySQL 特别怕 NUMA?

因为这些系统:

  • 内存访问频繁
  • cache 命中率敏感
  • latency 极其重要

尤其 Redis:

单线程模型。

如果:

  • CPU 在 node0
  • 内存在 node1

每次访问都跨 NUMA:

延迟直接抖动。

所以 Redis 官方甚至建议:

echo never > /sys/kernel/mm/transparent_hugepage/enabled以及:numactl --interleave=all或者直接:关闭 NUMA。

七、虚拟化里 NUMA 更恐怖

KVM/VMware 如果 NUMA 没配好:

会出现:

虚拟机 vCPU 在 node0虚拟机内存 在 node1

结果:

  • 虚机性能不稳定
  • 数据库随机抖动
  • CPU ready升高
  • 延迟飘忽

很多人:

疯狂优化 guest OS。

实际上:

问题在宿主机 NUMA。


八、真正的 Linux 高手,会建立“硬件拓扑脑图”

他们看服务器时:

脑子里会自动出现:

Socket ├── NUMA Node │    ├── CPU Core │    ├── L3 Cache │    └── Local Memory

他们会思考:

  • 中断在哪个 NUMA
  • 网卡在哪个 NUMA
  • NVMe 属于哪个 NUMA
  • Pod 被调度到哪个 NUMA
  • HugePage 属于哪个 NUMA

这才是真正理解现代 Linux。


九、很多所谓“高级运维”其实停留在 2012 年

他们会:

  • systemctl
  • shell
  • nginx
  • mysql 主从

但:

  • 不懂 NUMA
  • 不懂 CPU cache
  • 不懂 page fault
  • 不懂 scheduler
  • 不懂 cgroup
  • 不懂 eBPF

这种能力:

在 AI + 云原生时代会越来越吃力。

因为未来的核心:

已经变成:

“系统架构 + 内核 + 算力调度 + 性能工程”


十、真正建议深挖的 Linux 内核方向

如果你真想进入:

高级架构 / SRE / AI基础设施

NUMA 是绕不过去的。

后面建议继续深入:

  1. CPU Cache
  2. Page Cache
  3. HugePage
  4. cgroup v2
  5. eBPF
  6. Scheduler
  7. IRQ Affinity
  8. DPDK
  9. RDMA
  10. Kubernetes Topology Manager

这些东西一旦串起来:

你会真正理解:

Linux 不是“操作系统”而是“现代数据中心资源调度内核”。

最新文章

随机文章