1. 从“一视同仁”到“远近亲疏”聊聊NUMA到底是个啥如果你用过那种老式的多CPU服务器或者现在的高性能工作站可能会觉得CPU访问内存嘛不就是“读”和“写”两件事所有内存条对CPU来说应该都一样快。我以前也是这么想的直到有一次在调试一个高性能计算任务时发现程序跑起来的速度怎么算都对不上硬件的理论峰值性能波动很大这才开始深入研究背后的原因。这就引出了我们今天要聊的NUMA。NUMA全称是Non-Uniform Memory Access中文叫“非统一内存访问”。这个名字听起来有点学术但其实道理很生活化。你可以把它想象成一个大家庭的居住模式。假设你家是一栋大别墅里面住了好几兄弟每个兄弟代表一个CPU别墅里有很多房间代表内存。在古老的UMA统一内存访问架构里所有兄弟去任何一个房间的距离和速度都是一样的大家很公平。但在NUMA架构里这栋别墅被分成了几个“套间”每个套间里住着一两个兄弟并且配属了离他们最近的几个房间。兄弟访问自己套间里的房间这叫“本地内存”速度飞快抬脚就到但如果他想去别的兄弟的套间里拿东西访问“远端内存”那就得穿过客厅、走过长廊速度自然就慢下来了。这种“远近亲疏”的差异就是“非统一”的由来。在现代多路服务器比如搭载了两颗或四颗至强CPU的机器和很多高端台式机上NUMA架构非常普遍。它的设计初衷是好的通过让CPU优先使用离自己最近的内存来提升整体效率。但如果你写的程序或者部署的应用“不懂事”让一个CPU核心频繁地去访问远端的内存那性能瓶颈就出现了这就是所谓的“NUMA效应”。所以搞清楚你手头的Linux系统到底有几个NUMA节点也就是几个“套间”每个节点包含了哪些CPU核心和多少本地内存就成了做性能调优、资源绑定的第一步。这就像打仗前先得有一张精确的布防图。下面我就结合自己这些年踩过的坑和积累的经验给你分享5种最常用、最高效的查询方法并详细说说它们各自在什么场景下最好用。2. 全能选手一眼看穿lscpu命令详解说到查看系统CPU信息lscpu命令绝对是大多数人的第一反应。它就像系统信息的“仪表盘”把CPU的架构、核心数、线程数、型号等信息整理得清清楚楚。对于NUMA节点信息它也能给你一个非常直观的概览。你只需要打开终端输入这个简单的命令lscpu输出信息会很长但我们需要重点关注以下几行架构 x86_64 CPU 运行模式 32-bit, 64-bit 字节序 Little Endian CPU 64 在线 CPU 列表 0-63 每个核的线程数 2 每个座的核数 16 座 2 NUMA 节点 2 厂商 ID GenuineIntel 型号名称 Intel(R) Xeon(R) Gold 6230 CPU 2.10GHz ... NUMA 节点0 CPU 0-15,32-47 NUMA 节点1 CPU 16-31,48-63这里的关键信息是座2和NUMA 节点2。在这个例子中“座”Socket指的就是物理CPU插槽的数量这里有两个物理CPU。而NUMA节点的数量也是2这通常在标准服务器中与物理CPU的数量一一对应。更棒的是lscpu在最后明确列出了每个NUMA节点具体包含了哪些CPU编号比如节点0管理着0-15和32-47号逻辑CPU。适用场景与个人体会快速概览当你需要最快速度知道系统有几个CPU插槽、几个NUMA节点时lscpu是最佳选择。命令简单信息集中。信息关联性强它能同时告诉你CPU拓扑每个Socket有多少Core每个Core有多少Thread和NUMA节点的映射关系帮你建立整体认知。新手上路首选不需要安装任何额外工具所有Linux发行版基本都自带零门槛。我刚开始接触NUMA调优时就特别喜欢先用lscpu摸个底。它能立刻告诉我这是一台“双路”服务器并且有两个NUMA节点心里马上就有谱了。不过它也有局限比如它不直接显示每个NUMA节点关联的内存大小。这时候我们就需要请出更专业的工具。3. 深入内核信息宝库探索/sys文件系统Linux系统有一个非常强大的设计就是“一切皆文件”。很多内核参数和硬件信息都以虚拟文件的形式暴露在/syssysfs目录下。对于NUMA信息这里有一个“宝藏路径”/sys/devices/system/node/。你可以直接用ls命令查看这个目录ls /sys/devices/system/node/如果系统支持NUMA你会看到类似node0、node1这样的目录每一个目录就代表一个NUMA节点。直接看目录数量你就知道了节点数。但这只是冰山一角。每个nodeX目录里都藏着对应节点的详细信息。我们以node0为例ls /sys/devices/system/node/node0/你会看到很多文件和子目录比如cpulist、cpumap、meminfo、hugepages等。这些都是纯文本文件可以直接用cat命令查看。查看节点0包含的CPU列表cat /sys/devices/system/node/node0/cpulist输出可能是0-15,32-47这和lscpu看到的信息一致但这是从内核视角直接读取的。查看节点0的内存信息非常有用cat /sys/devices/system/node/node0/meminfo这个命令的输出类似/proc/meminfo但它是针对特定NUMA节点的你会看到Node 0 MemTotal、MemFree、MemUsed等关键指标。这是我做内存绑定时必看的信息它能清晰告诉我每个节点上有多少可用的本地内存。适用场景与个人体会获取最详细、最底层的信息当你需要知道每个NUMA节点精确的内存使用情况、CPU位图cpumap时/sys是唯一的选择。脚本的自动化能力非常强。编程和脚本自动化因为信息都以标准文件形式存在用Shell脚本、Python等语言去解析和监控这些信息极其方便。比如写一个监控脚本定期抓取每个节点的内存剩余量。理解内核数据结构通过查看这些文件你能更直观地理解内核是如何管理和抽象NUMA单元的。我印象很深的一次是排查一台数据库服务器的性能抖动。lscpu和numactl都显示内存充足但通过cat /sys/devices/system/node/node1/meminfo发现节点1的本地内存虽然总量大但已经被几个进程几乎占满导致新进程被挤到远端内存上运行。问题根源一下子就锁定了。/sys提供的信息粒度最细是深度调优的利器。4. NUMA专属瑞士军刀numactl工具实战如果说lscpu是仪表盘/sys是工程图纸那么numactl就是专门为NUMA打造的一套“瑞士军刀”。它不仅能查看硬件拓扑更能直接控制进程的内存和CPU绑定策略。首先你可能需要安装它# 在CentOS/RHEL/Fedora上 sudo yum install numactl # 在Ubuntu/Debian上 sudo apt-get install numactl安装后查看NUMA硬件拓扑的命令非常直观numactl --hardware这个命令的输出信息堪称“豪华”available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23 node 0 size: 65436 MB node 0 free: 12345 MB node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31 node 1 size: 65536 MB node 1 free: 23456 MB node distances: node 0 1 0: 10 21 1: 21 10我们来逐条解析available明确告诉你系统有2个可用节点0和1。node X cpus列出每个节点管理的所有逻辑CPU编号。注意看这里的编号排列可能和lscpu展示的物理核心分组视角略有不同但本质上是一致的。node X size/free这是核心优势它直接给出了每个NUMA节点的总内存大小和当前空闲内存。在做资源规划和绑定时这个信息至关重要。比如你想把一个大内存进程绑定到节点0就必须先确认节点0有足够的空闲内存。node distances这是一个非常关键但常被忽略的信息。它表示节点间的“距离”或访问延迟成本。如上所示节点0访问自己的本地内存距离10比访问节点1的内存距离21要快。这个数值是相对的比值21/10≈2大致反映了访问远端内存的延迟倍数。这解释了为什么跨节点访问会影响性能。适用场景与个人体会一站式信息获取这是我最推荐的、查看完整NUMA信息的命令。它把CPU、内存、节点距离全打包给你了不用东拼西凑。资源绑定操作的前置检查在运行numactl --cpunodebind0 --membind0这类绑定命令之前必须用--hardware参数查看目标节点的CPU和内存资源是否充足。理解访问成本node distances让你对跨节点访问的性能损耗有一个量化的概念对于设计高性能程序的数据布局非常有启发。在实际工作中numactl --hardware是我做NUMA相关工作的标准起手式。它给出的信息足够权威和全面足以支撑大部分决策。比如部署一个Redis实例我会先用它看看哪个节点空闲内存多然后将其绑定过去确保它能独占本地内存资源。5. 传统经典的侧面印证解析/proc/cpuinfo/proc/cpuinfo是一个老牌的、用于查看CPU详细信息的文件。它虽然不直接显示“NUMA节点”这个概念但可以通过“physical id”这个字段来间接推断物理CPUSocket的数量在大多数标准服务器上这通常等同于NUMA节点的数量。查看所有CPU信息cat /proc/cpuinfo信息量很大我们关注每一段对应一个逻辑CPU中的physical id和core id。一个更高效的方法是使用grep和排序去重grep physical id /proc/cpuinfo | sort -u输出可能像这样physical id : 0 physical id : 1这表示系统中有两个不同的physical id即两个物理CPU插槽。结合我们之前的知识这通常意味着有两个NUMA节点。你还可以用一条更强大的命令来查看完整的拓扑cat /proc/cpuinfo | grep -E processor|physical id|core id | paste - - -这会把processor逻辑CPU编号、physical id物理CPU和core id核心编号三行合并为一行显示让你清楚地看到逻辑CPU是如何被分配到各个物理核心上的。适用场景与个人体会兼容性检查在一些非常古老或嵌入式的Linux系统上可能没有numactl甚至lscpu的输出格式也不同。/proc/cpuinfo是几乎100%存在的可以作为最后的备用手段。理解超线程通过对比processor数量、core id数量和physical id数量你可以清晰地计算出系统是否开启了超线程SMT。例如physical id有2个唯一的core id有32个但processor有64个这就说明每个物理核心有2个线程超线程开启。侧面印证当你不确定其他工具的输出时可以用这个方法从CPU视角进行交叉验证。这个方法更像是一个“考古学”工具它从最原始的CPU信息出发让你推导出系统拓扑。在新系统中它的重要性已被lscpu和numactl取代但作为知识储备和备用方案了解它绝对没坏处。我曾经在一台内核比较旧的自研设备上就是靠分析/proc/cpuinfo才弄明白它的CPU布局的。6. 方法对比与实战场景选择指南好了一口气介绍了五种方法是不是有点眼花缭乱别急我帮你总结了一张表并分享几个我常用的实战场景让你能快速选择最合适的工具。方法命令/路径主要信息优点缺点最佳适用场景全能概览lscpuCPU架构、Socket数、Core/Thread数、NUMA节点数及CPU列表系统自带信息全面直观关联性强不显示内存信息快速了解系统拓扑新手首选内核详情/sys/devices/system/node/每个NUMA节点的详细内存信息(MemTotal, MemFree等)、CPU位图信息最底层、最详细适合脚本自动化需要遍历文件查看不如命令直接深度性能调优、编写监控脚本专业权威numactl --hardware节点内存大小/空闲量、CPU列表、节点间访问距离NUMA专属工具信息最全最权威包含关键内存数据需要额外安装NUMA资源绑定前的标准检查一站式获取所有信息传统推断grep physical id /proc/cpuinfo物理CPU IDSocket数任何系统都存在兼容性极好不直接显示NUMA需间接推断无内存信息老旧或特殊系统下的兼容性备用方案实战场景选择指南“我新拿到一台服务器想快速看看它有几个NUMA节点。”首选lscpu。打开终端输入命令5秒内答案就在“NUMA节点”那一行里。简单粗暴有效。“我要部署一个对内存带宽敏感的应用如Redis、Memcached想把它绑到最合适的NUMA节点上。”标准流程先运行numactl --hardware。重点看每个节点的size和free内存选择一个空闲内存充足的节点。然后使用numactl --cpunodebindN --membindN来启动你的应用N是节点编号。这是保证应用获得最佳本地内存访问性能的标准操作。“我的程序运行时性能不稳定怀疑是跨NUMA节点访问内存导致的想深入看看。”深度调查结合使用numactl --hardware查看节点距离理解延迟成本。同时用cat /sys/devices/system/node/nodeX/meminfo监控程序运行时各节点内存的使用变化看是否出现某个节点内存被榨干而另一个节点却很空闲的不均衡情况。这种不均衡往往是性能问题的根源。“我想写一个运维监控脚本定期收集集群中每台机器的NUMA内存使用率。”自动化之道毫无疑问选择/sys文件系统。写一个Shell脚本或Python脚本循环读取/sys/devices/system/node/node*/meminfo文件解析MemTotal和MemFree计算使用率。因为文件接口标准这种方法最可靠、最易于集成到监控系统中。“在一台陌生的、工具不全的旧机器上我该怎么判断”备用方案尝试lscpu。如果不可用就求助于cat /proc/cpuinfo | grep physical id | sort -u数一数有多少个不同的物理ID这通常就是NUMA节点数。虽然信息有限但能救急。说到底这些方法并不是互斥的它们就像工具箱里不同的螺丝刀各有各的用武之地。我个人的习惯是登录新机器先lscpu宏观把握做绑定时必用numactl --hardware确认资源写自动化脚本则和/sys打交道最多。理解它们各自的输出和特点你就能在面对不同的NUMA相关问题时游刃有余地选出最趁手的那把工具。