NUMA架构如何影响服务器性能？从拓扑到测试实战全解析

1. 同配置不同命：先从一次压测“翻车”说起

搞服务器测试的人，大概都遇到过这种诡异情况：两台机器，CPU型号一样、核心数一样、内存总量一样，跑同一个基准测试，结果却能差出30%甚至一倍。如果你只看规格表，怎么都想不通。但只要你把视角从“有多少核、有多少G内存”切换到“这些核和内存是怎么连在一起的”，答案立刻就浮出来了——NUMA，Non-Uniform Memory Architecture，非一致内存访问架构。

我第一次对NUMA产生强烈感知，是在测一台双路服务器的Stream内存带宽时。这台机器理论上有32核、512GB内存，跑Memtest和CPU-Z看规格都正常。但无论怎么调优，多线程内存带宽都卡在某个诡异的上限，怎么都上不去。后来把测试线程和内存分配都锁在同一个NUMA节点里，带宽立刻暴涨。这件事让我意识到，服务器测试如果只懂看参数，不会看拓扑，那性能数据基本就是在“盲人摸象”。

这篇文章不是讲CPU架构课的，而是从一个服务器测试工程师的角度，聊清楚三件事：NUMA到底是怎么影响性能的、怎么看懂一台服务器的拓扑图、以及做基准测试时怎么避免被NUMA“暗算”。适合刚入行的服务器测试、性能测试、系统运维同学阅读，也适合那些被“高配置跑不出高性能”困扰的开发者。

核心观点先摆出来：在NUMA架构下，CPU访问不同位置的内存，速度和带宽是不一样的；考核性能不能只看“总量”，必须结合“距离”和“拓扑”来判断。同一台服务器，测试策略不同，结果能差出一大截，这跟硬件好坏没关系，纯粹是数据放错了位置。

2. 从SMP到NUMA：为什么老办法搞不定多路服务器

2.1 总线瓶颈：SMP时代的“共享一条道”

要想理解NUMA，得先知道它替代的是什么。早期多CPU服务器普遍采用SMP（Symmetric Multi-Processing，对称多处理）架构。所谓对称，就是所有CPU通过一条共享的前端总线连接到同一个内存控制器，访问内存时要统一经过这根总线仲裁。好处是编程模型简单，每个CPU访问内存的延迟一致，操作系统不用关心“数据离谁更近”这种问题。

坏处也很致命——总线带宽是所有CPU共享的。CPU从2路加到4路、8路，总线的压力跟着成倍增长，但总线的物理宽度和频率不会同比例提升。结果就是，CPU数量增加以后，单个CPU能分到的内存带宽反而下降，甚至出现CPU越多、某些场景性能越差的倒挂现象。这就是所谓的前端总线瓶颈。

我打个比方：SMP架构相当于所有住户都走同一条小区大门，高峰期进出全堵在那一个门口。CPU少的时候还凑合，一旦住户变多，门就成瓶颈了。解决这个问题只有两条路：要么把门加宽（提升总线带宽，但物理上有极限），要么给每栋楼开自己的门（分布式内存）。

2.2 NUMA的解法：每个CPU带一块“自留地”

NUMA的思路，本质上是变“共享”为“分布”。每个CPU（或者每颗物理处理器）都集成自己的内存控制器，直接连着一部分物理内存。这块内存对当前CPU来说就是“本地内存”（Local Memory），访问它的延迟低、带宽高。而访问其他CPU所连接的内存时，需要经过CPU之间的互联通道（比如Intel的UPI、AMD的Infinity Fabric）绕一圈，这就是“远端内存”（Remote Memory），延迟更高、带宽更低。

操作系统和硬件把CPU和它直连的内存划归为一个“节点”（NUMA Node）。一台双路服务器通常有2个NUMA节点，四路服务器可能是4个甚至更多（如果开了SNC之类模式，单颗CPU内部还能再分）。每个节点内部，CPU访问本地内存是“近水楼台”；跨节点访问，就要交“过路费”。

这个“过路费”到底有多贵？不同代际的CPU、不同互联协议下差别很大，但总的来说，跨节点访问的延迟通常比本地访问高1.3到2倍，在某些竞争激烈的场景下，带宽甚至可能只剩本地访问的一半不到。而且CPU和CPU之间的互联链路是共享的，多个节点同时互相访问时，还会互相挤占。

2.3 NUMA节点不是“平均分蛋糕”那么简单的逻辑分区

还要澄清一个常见误解：NUMA节点不是操作系统对内存做的软件分区，它是硬件层面的物理连接关系。操作系统只是在启动时读取ACPI和SRAT表，感知到这个拓扑结构，然后尽量把内存页面分配到“离请求它的CPU最近”的节点上。

但操作系统也不是总能做到完美。比如一个进程先在一个节点上申请了内存，后来它的线程被调度到了另一个节点，或者通过numactl指定了不同的执行节点，这时它访问的内存就成了远端内存。更复杂的情况是，有些多线程程序会由主线程统一分配内存池，然后分发给各工作线程并行处理，结果所有工作线程都在访问主线程所在节点的内存——如果工作线程被分散调度到其他节点，那整个进程就在疯狂跨节点访问，性能可想而知。

做性能测试的人，脑子里必须有一张“数据流向图”：哪些数据在哪个节点上、哪些线程在哪个核上跑、它们之间距离几何。很多测试数据不好看，根本原因是这张图乱了，而不是硬件本身不行。

3. 看拓扑：这几条命令能帮你画出服务器的“内存地图”

3.1 lscpu：第一眼就看清物理架构

在Linux服务器上，我拿到一台新机器，第一个命令永远是lscpu。这不只是看型号和核数，更要看它输出的架构布局：

bash复制$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              32
On-line CPU(s) list: 0-31
Thread(s) per core:  1
Core(s) per socket:  16
Socket(s):           2
NUMA node(s):        2
Vendor ID:           GenuineIntel
Model name:          Intel(R) Xeon(R) Gold 6330 CPU @ 2.00GHz
NUMA node0 CPU(s):   0-15
NUMA node1 CPU(s):   16-31

看输出里的几个关键字段：Socket(s)是物理CPU颗数，Core(s) per socket是每颗CPU的核数，NUMA node(s)是系统识别出的NUMA节点数。如果NUMA node(s)等于socket数 × 每颗CPU内的NUMA节点数，那说明没有启用SNC之类的分片模式；如果节点数比物理CPU数还要多，说明每颗CPU内部又做了细粒度划分。

NUMA node0 CPU(s): 0-15和NUMA node1 CPU(s): 16-31这两行最直接地告诉你：哪些核离哪些内存近。绑核和内存分配策略，都基于这个映射关系。

3.2 numactl --hardware：这条命令比lscpu更直白

如果说lscpu看的是“逻辑视图”，那numactl --hardware看的就是“物理视图和距离矩阵”：

bash复制$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 251723 MB
node 0 free: 200125 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 251658 MB
node 1 free: 210342 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

输出下半部分的node distances是NUMA拓扑的灵魂。这是一个相对距离矩阵，不是纳秒数，而是“相对代价”：数字越小，说明两个节点之间通信越“便宜”。比如这里node 0访问自己的本地内存，距离是10；访问node 1的内存，距离是21——跨节点访问大约是本地访问的2.1倍代价。这个数字直接决定了一台机器对内存敏感的负载能跑多好。

如果机器节点多，距离矩阵会大一些。比如四路服务器，节点间的距离可能不是对称的：node 0和node 1距离是10和21，node 0和node 2可能更远（比如30），因为访问最远的节点要经过更多跳的互联链路。距离矩阵反映了每个节点对之间的物理邻近度和跳数，是判断“把任务放在哪、把数据放在哪”最重要的依据。

3.3 lstopo：把拓扑“画”出来

lscpu和numactl输出的是文字信息，虽然完整，但不够直观。lstopo（属于hwloc工具包）可以直接生成拓扑图和树形文本，把socket、NUMA节点、L1/L2/L3缓存、内存控制器之间的拓扑关系画成一棵树。

bash复制$ lstopo --of txt
Machine (503GB)
  Package L#0
    NUMANode L#0 (P#0 251GB)
      L3 L#0 (30720KB)
        L2 L#0 (2560KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
          PU L#0 (P#0)
          PU L#1 (P#16)
        ...
    NUMANode L#1 (P#1 251GB)
      ...
  Package L#1
    NUMANode L#2 (P#2 251GB)
      ...

从hwloc的输出能清楚看到，哪几个核共享一个L3缓存、哪些核被划在同一个NUMA节点里、L3缓存和内存控制器的挂接关系。在测试时，如果我想确认“把两个线程放在同一颗CPU的不同核上，能不能共享L3”，用lstopo一查就一目了然。

3.4 跨双路平台看拓扑要注意：Socket、Die、CCX的层级关系

对于双路Intel平台，拓扑相对简单：一颗物理CPU通常就是一个NUMA节点，内部有若干个Die（芯片内部的小芯粒）。但对于AMD EPYC或者Intel的双Die封装，情况复杂得多：一颗物理CPU内部可能分成多个Die，每个Die自带内存控制器，如果BIOS开启了NUMA per socket或者SNC（Sub-NUMA Clustering）模式，一颗CPU会被系统识别成2个甚至更多NUMA节点。

这意味着什么？举例来说，一颗64核的EPYC处理器，关闭SNC时是一个64核的大NUMA节点，跨Die访问内存虽然在一个“物理Socket”内，延迟仍然明显，但操作系统感知不到，会把它当作本地访问来调度；开启SNC后，这颗CPU变成2个或4个NUMA节点，调度器能做出更精细的本地化决策。到底开不开SNC，取决于负载的内存访问模式——没有绝对的好坏，测试前必须搞清楚BIOS当前是什么状态。

实操建议：在做任何性能对比测试之前，先记录一份numactl --hardware和lscpu的完整输出，连同BIOS版本和NUMA相关选项一起存档。否则，你测出来的数据可能根本不是同一架构配置下的产物，后面所有结论都站不住脚。

4. 实测数据：本地内存和远端内存的差距到底有多大

4.1 延迟：跨节点访问比隔一个L3还要“绕远”

延迟是NUMA违反最直观的受害者。考虑一个简单场景：一个核心需要做指针链式访问，每次读取一个随机指针地址，整个工作集大小是4KB，保证完全命中L1缓存——这种测试基本看不出NUMA影响。但如果把工作集扩大到几百MB，超过L3容量，必须访问内存，本地和远端的差异就来了。

我实测过几代服务器平台，本地内存访问延迟大约在80到120纳秒这个量级，跨节点访问通常要飙到130到220纳秒。换算下来，每百万次远程内存访问比本地访问慢大约50到100毫秒。如果程序里有大量指针链、哈希表探测、数据库索引遍历这类延迟敏感操作，跨节点代价直接反映到响应时间上。

更隐蔽的是，当多个节点的CPU同时互相访问远端内存时，互联链路上的拥塞会把延迟进一步拉高。也就是说，延迟差不是固定的，而是随系统负载动态恶化的。如果你的性能测试结果是基于“整机多负载并发”得出的，那NUMA造成的影响会比单线程测试时大得多。

4.2 带宽：多线程带宽测试里的“假瓶颈”

带宽方面，Stream测试是内存带宽的经典基准。同一台双路服务器上，不同测法能得出完全不同的结论：

这个表是我在很多次测试里反复验证过的经验。最典型的“坑”是：跑Stream时直接./stream不加任何numactl参数，系统默认的内存策略是把新页面均匀交错分配到两个节点上（interleave或first-touch策略视系统配置而定）。每个CPU的本地带宽只发挥了一半，实测数字自然远远达不到峰值，然后你以为是内存配置有问题，查了半天BIOS，其实纯属NUMA策略没设对。

4.3 一个容易误判的情况：跨节点访问“看起来正常”但数据不对

还有一个值得单独说的现象：不是所有NUMA违反都会导致性能雪崩。如果你的程序是编译型、数据局部性好，操作系统又刚好把内存分配到了访问方本地节点，那性能可能和最优状态相差无几。但如果程序是长时间运行的、线程会反复创建销毁和迁移，内存页可能慢慢散落到各个节点上。

这也是为什么很多测试“第一次跑是好的，第二次跑就崩了”——第一次跑完，内存页面还在原来的节点上，进程退出后页面释放；第二次新进程启动时，内存分配策略又变了，或者进程启动时被调度到了另一个节点的CPU上。你根本没有改过任何代码和配置，测试结果却不稳定。排除了外部因素后，就要怀疑是不是NUMA内存策略在作祟。

实操建议：做内存或CPU密集型的性能测试，不要只跑一遍就下结论。至少用numactl固定两种场景——严格本地模式和默认系统策略模式——各跑三遍以上，取平均值和中位数，才能真正判断机器本身的能力。

5. 当“性能下降”成为现象：一次IO吞吐异常问题的完整排查过程

5.1 现象和初步判断

有一回，我在帮业务团队排查一个问题：某套存储转发服务，代码没变、版本没变，从一台旧机器迁移到一台新机器后，IO吞吐性能反而下降了将近30%，延迟P99也涨了一倍多。单看硬件参数，新机器CPU更强、内存更大、网卡是新的25G卡，怎么看都应该更快才对。用户反馈时几乎是在质疑硬件——是不是这批次服务器有问题？

我做的第一件事，不是换硬件，也不是查代码，而是把新机器和旧机器的NUMA拓扑做了个对比。果然，两台机器的CPU型号和数量完全不同：旧机器是双路8核老平台，每颗CPU内存通道少；新机器是双路16核新平台，支持更多内存通道。但这不是关键，关键是新机器BIOS默认开启了某个分片模式，系统的NUMA节点数由2变成了4。每个节点的本地内存变小了，跨节点访问变得更加频繁。

5.2 排查链路全记录

整个排查过程，按下面这条路走下来：

第一步：跑基线测试确认问题边界。 先用dd或fio测磁盘，用iperf或qperf测网络，分别验证存储和网络的原始性能。当时fio单线程和iperf单流测试结果都正常，说明物理链路没问题。问题出在业务程序的多进程并发场景下。

第二步：观察进程运行状态。 用pidstat和perf查看业务进程的CPU利用率、上下文切换次数，以及cache miss情况。perf stat -e cache-misses,cache-references,node-load-misses输出的数据里有个关键字段——node-load-misses，表示跨NUMA节点加载内存的次数。这个数值在当时高得离谱，占所有内存访问的40%以上。这就实锤了：进程在大量访问远端内存。

第三步：定位进程和内存的分布情况。 用numastat -p <pid>查进程的内存分配情况，输出显示进程的物理内存页面散布在多个NUMA节点上，而不是集中在某个节点。同时用taskset或查看/proc/<pid>/status里的Cpus_allowed_list，发现进程的多个线程实际上允许在全部CPU上调度。线程不断在不同节点之间迁移，导致每次访问自己的数据都要跨节点。

第四步：修改启动方式验证归因。 临时用numactl --cpunodebind把进程绑到某个节点，同时设置--membind让内存分配只从该节点出，重跑业务压测。数据立刻恢复了正常水平，甚至比旧机器还快。这就彻底确认了问题不是硬件缺陷，而是NUMA策略没有配合好。

5.3 最终修复方案

定位到问题根因后，修复方向就非常明确了。这类多进程IO密集服务，最合适的策略并不是把所有东西都绑死在一个节点上——那样会把压力集中在一个内存控制器和一个网卡中断上。正确的做法是：把服务拆分成和NUMA节点数量对应的几个进程实例，每个实例绑定到固定节点，网卡的多队列中断也按照节点分组绑定到对应CPU上，各进程只使用本节点内存。

这套配置做完之后，整体吞吐提升了大约40%，延迟抖动也明显收窄。值得注意的是，修复方案里没有改一行业务代码，纯粹是让操作系统和业务进程理解了硬件的物理结构。这就是“总量不是性能的全部”最真实的案例。

5.4 此类排查中常被忽略的两个因素

一个是irqbalance服务的干扰。系统自带的irqbalance会定期在CPU之间均衡网卡中断，实现路径是改变中断的CPU亲和性。在NUMA架构下，如果网卡中断被迁移到了和网卡不在同一个节点的CPU上，那么每次收包后的内存访问都会变成跨节点操作，导致吞吐下降。排查时要检查/proc/irq/<中断号>/smp_affinity，必要时直接关掉irqbalance，手工把网卡队列中断绑到正确的CPU集合。

另一个是驱动内存分配标志。dpdk、spdk这类用户态驱动靠大页内存做数据收发，如果大页内存分配的节点和网卡所在的PCIe控制器不在同一NUMA节点，跨节点访问的代价会直接吃掉数据面性能。检查方法很简单：看一下网卡在lspci -v里关联的NUMA node编号，再对照一下cat /sys/devices/system/node/node*/hugepages的分配情况。

6. 测试方案里的NUMA纪律：怎么把“测不准”变成“测得对”

6.1 测试前必备的拓扑基线存档

我经手过的每一个正式性能测试项目，都要求测试环境信息里必须包含一组标准的NUMA存档文件。没有这套东西，测试报告在架构上有本质缺陷。建文件夹存档下面这些输出：

bash复制# 核心拓扑信息
lscpu > lscpu.txt
numactl --hardware > numactl_hardware.txt
numactl --show > numactl_show.txt
lstopo --of txt > lstopo.txt

# 内存和互联状态
cat /sys/devices/system/node/node*/meminfo > numa_meminfo.txt
cat /sys/devices/system/node/node*/numastat > numa_stat.txt

# BIOS版本和NUMA相关选项
dmidecode -t bios | grep -i version
dmidecode -t memory | grep -E "Locator|Speed|Size|Type"

别看只是几条命令，真出问题的时候，这些存档能帮你判断“到底是工况变了、BIOS配置变了、还是机器本身有差异”。比没有存档全靠猜要高效得多。

6.2 numactl的三种典型策略与适用场景

numactl是Linux下控制NUMA策略的核心工具，参数虽然多，但核心就两类：绑CPU和绑内存。

bash复制# 场景一：全面本地化——CPU和内存都锁定在node0
numactl --cpunodebind=0 --membind=0 ./benchmark

# 场景二：只绑内存，让系统调度CPU（适合负载不均衡时）
numactl --membind=0 ./benchmark

# 场景三：内存交错分配，让内存带宽跑满
numactl --interleave=all ./benchmark

我自己测高并发网络转发类负载时，倾向于--cpunodebind和--membind搭配使用，因为这类负载数据面和处理面在同一个进程内，本地性要求极高。而测内存带宽密集型数值计算时，可以把CPU分散到两个节点上跑两组进程，每组独立绑核绑内存，让两套内存控制器并行干活。

有同学会觉得--interleave=all能把所有内存带宽都用起来，所以性能最好。这是个误区。interleave模式是把页面按顺序轮流放到每个节点上，理论上确实能利用多个内存控制器的带宽，但进程访问每一个内存页都有50%概率要跨节点，延迟会高于本地访问。它只适合那些单个进程的工作集就大到一个节点内存装不下的场景，对这种场景，总比内存反复swap到磁盘强得多。

6.3 基准测试报告的“最低道德标准”

一份合格基准测试报告，至少应该交代清楚这五条信息：

• 测试机的NUMA节点数量和各节点的CPU/内存分布；
• 测试进程的绑核方式（taskset -c还是numactl --cpunodebind）；
• 内存分配策略（--membind、--interleave还是默认）；
• BIOS的NUMA相关开关状态（SNC/Cluster模式是否开启）；
• 每个测试用例重复次数和波动范围（不是只给一个最好值）。

缺少任何一条，测试结果在NUMA架构下都可能是误导性的。我见过不少项目因为换了一台机器、BIOS默认配置不同，导致性能回归数据“看起来”差了很多，最后发现根本不是代码问题，纯粹是测试方法没对齐。这些沟通成本，原本只要按上面清单存档就能完全避免。

7. 针对不同负载的NUMA策略：数据库、虚拟化与网络高吞吐场景

7.1 内存数据库和数据库类负载：宁缺毋滥，锁定本地性

内存数据库（比如Redis）或者对延迟敏感的MySQL实例，数据基本都在内存里，对内存访问延迟的敏感度极高。这类进程如果线程被调度到别处，或者内存被分配到了别的节点，单单一次远程访问就可能导致P99延迟翻倍。

生产环境里我见过最常见的配置错误是：Redis单实例部署，任务管理器显示32个逻辑CPU，然后系统调度器有时候把它的主线程放到node0，有时候放到node1——操作系统的负载均衡策略完全不知道Redis其实是单线程延迟敏感型应用。结果就是，每次恢复或者重启Redis之后，性能各不相同。

解决办法很简单，单实例Redis直接绑在一个NUMA节点内：

bash复制# 以node0为例，将Redis绑定在node0的CPU和内存上
numactl --cpunodebind=0 --membind=0 /usr/local/bin/redis-server /etc/redis/redis.conf

如果是部署多实例，每个实例绑一个独立节点，互不干扰。这样内存控制器和L3缓存各用各的，避免互相抢占。

7.2 虚拟化场景：物理CPU和虚拟CPU的拓扑映射

KVM或者VMware环境做性能测试时会遇到一个特殊问题：虚拟机内部的NUMA拓扑，和物理机顶层的NUMA拓扑不一定对应。现代虚拟化平台默认会尝试把vCPU物理绑定到同一个NUMA节点上，让虚拟机内的“本地内存访问”在物理层也是本地访问。但有些运维配置可能会忽略这个映射。

举例来说，一个4 vCPU、32GB内存的虚拟机，如果物理机有2个NUMA节点，而虚拟机没有配置cpu pinning，那这个虚拟机的vCPU可能被调度到两个物理节点上，虚拟机的内存页面也分散在两个节点。此时虚拟机里跑的操作系统感知不到这种跨节点代价，它以为自己在访问本地内存，实际上已经付出了很大的代价，整个虚拟机的性能都会下降。测试虚拟机性能时，我建议用virsh vcpuinfo查看vCPU所在的物理CPU，确认拓扑对齐。

7.3 网络高吞吐场景：网卡队列、中断亲和性与NUMA节点一致

高速网络处理（尤其是DPDK或AF_XDP这类内核旁路方案）对NUMA的敏感度，比纯CPU计算负载要高得多。当你用25G或100G网卡做高吞吐压测时，如果网卡的PCIe控制器挂在node0，对应的网卡队列中断也绑定在node0的CPU上，但你业务进程和内存池分配在node1，那么每次DMA写入内存之后，CPU读取数据都成了一次跨节点访问——延迟翻倍、带宽减半。在数据面处理里，这基本上等于废掉一半的转发能力。

正确做法是：先看网卡挂在哪个NUMA节点：

bash复制$ cat /sys/bus/pci/devices/0000:3b:00.0/numa_node
0

然后把这个网卡对应的队列中断全部绑到同一个节点的CPU上，业务进程、内存大页池也全部放在同一个节点。手动设置时，矩阵中每个节点对应的CPU列表从lscpu或numactl输出中提取。

7.4 常用的检查命令小结

做上面的检查、排障和验证时，我高频使用的是这些命令：

• numastat：查看系统各节点的内存命中/未命中统计，判断是否大量跨节点；
• perf stat -e node-load-misses,node-store-misses：测定程序中跨节点的内存访问事件；
• taskset -pc <pid>：查看/修改进程当前CPU亲和性；
• /proc/<pid>/status 中的 Mems_allowed_list：查看进程允许分配内存的节点范围；
• watch -n1 numastat：实时观测各节点内存分配动态，判断策略调整是否生效。

经验分享：只做一次检查往往会漏掉瞬时波动，建议加-n1持续观察一段时间，尤其是测试进程还在跑的时候。如果发现node-load-misses占比稳步爬升，说明进程运行一段时间后内存页面开始往别的节点飘散——这是很多长稳测试“跑到一半开始变慢”的元凶。

8. 关于“总量不是全部”的一点总结性思考（不算总结的个人经验）

测试这条路，本质上是不断确认“硬件被正确使用的能力”。NUMA教给测试工程师的，是重新审视“性能数字是怎么来的”这个过程本身。总量、核心数、内存容量，这些数字只是机器的“体格”；而内存访问的本地性、CPU与数据之间的物理距离、拓扑结构生成的数据路径，才是决定一台机器能不能发挥真正实力的“经脉”。体检报告正常，不代表这个人能跑马拉松——你还要看心肺功能怎么配合、血氧怎么输送。

在我自己日常测试中，已经形成一套习惯：拿到一台新机器，花30分钟把lscpu、numactl --hardware、lstopo的输出过一遍；跑基准前先确认测试进程和内存是否待在它们该在的节点里；报告里永远附上拓扑和绑核信息。这点投入换来的，是之后排查问题时少走无数弯路。

最后再分享一个小技巧：当你对比两台服务器的性能时，如果规格完全一样但结果不同，先别急着怀疑硬件翻新或翻修，先检查两台机器的BIOS选项是否一致。SNC开没开、NUMA相关选项有没有被改动，都会导致拓扑结构发生巨大变化。这类问题，靠numactl --hardware一查便知，很多时候比翻半天硬件日志快得多。