十年后数据库还是不敢拥抱NUMA - 续篇

背景

十年后数据库还是不敢拥抱NUMA， 这篇经典的纠正大家对NUMA 认知的文章一晃发布快3年了，这篇文章的核心结论是：

• 之所以有不同的NUMA Node 是不同的CPU Core 到不同的内存距离远近不一样所决定的，这是个物理距离
• 程序跑在不同的核上要去读写内存可以让性能差异巨大，所以我们要尽量让一个程序稳定跑在一个Node 内
• 默认打开NUMA Node 其实挺好的

写这个续篇是我收到很多解释，因为跨Node 导致性能抖动，所以集团在物理机OS 的启动参数里设置了 numa=off ，也就是不管BIOS 中如何设置，我们只要在OS 层面设置一下 numa=off 就能让程序稳定下来不再抖了！ 我这几年也认为这是对的，只是让我有点不理解，既然不区分远近了，那物理上存在的远近距离(既抖动)如何能被消除掉的呢？ 所以这个续篇打算通过测试来验证下这个问题

设置

BIOS 中有 numa node 设置的开关(注意这里是内存交错/交织)，不同的主板这个BIOS设置可能不一样，但是大同小异，基本都有这个参数

Linux 启动引导参数里也可以设置numa=on(默认值)/off ，linux 引导参数设置案例：

#cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-327.x86_64  ro crashkernel=auto vconsole.font=latarcyrheb-sun16 vconsole.keymap=us BIOSdevname=0 console=tty0 console=ttyS0,115200 scsi_mod.scan=sync intel_idle.max_cstate=0 pci=pcie_bus_perf ipv6.disable=1 rd.driver.pre=ahci numa=on nosmt=force

注意如上的 numa=on 也可以改为 numa=off 看完全置篇要记住一条铁律：CPU到内存的距离是物理远近决定的，你软件层面做些设置是没法优化这个距离，也就是没法优化这个时延 (这是个核心知识点，你要死死记住和理解，后面的一切实验数据都回过头来看这个核心知识点并揣摩)

实验

测试机器CPU，如下是BIOS numa=on、cmdline numa=off所看到的，一个node

#lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                96
On-line CPU(s) list:   0-95
Thread(s) per core:    2
Core(s) per socket:    24
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz
Stepping:              4
CPU MHz:               2500.000
CPU max MHz:           3100.0000
CPU min MHz:           1000.0000
BogoMIPS:              4998.89
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              33792K
NUMA node0 CPU(s):     0-95

测试工具是lmbench，测试命令：

for i in $(seq 0 6 95); do echo core:$i; numactl -C $i -m 0 ./bin/lat_mem_rd -W 5 -N 5 -t 64M; done >lat.log 2>&1

上述测试命令始终将内存绑定在 node0 上，然后用不同的物理core来读写这块内存，按照前一篇 这个时延肯定有快慢之分 BIOS和引导参数各有两种设置方式，组合起来就是四种，我们分别设置并跑一下内存时延，测试结果：

测试原始数据如下(测试结果文件名 lat.log.BIOSON.cmdlineOff 表示BIOS ON，cmdline OFF )：

//从下面两组测试来看，BIOS层面 on后，不管OS 层面是否on，都不会跨node 做交织，抖动存在
//BIOS on 即使在OS层面关闭numa也不跨node做内存交织，抖动存在
//默认从内存高地址开始分配空间，所以0核要慢
#grep -E "core|64.00000" lat.log.BIOSON.cmdlineOff 
core:0 //第0号核
64.00000 100.717 //64.0000为64MB， 100.717 是平均时延100.717ns 即0号核访问node0 下的内存64MB的平均延时是100纳秒
core:24
64.00000 68.484
core:48
64.00000 101.070
core:72
64.00000 68.483
#grep -E "core|64.00000" lat.log.BIOSON.cmdlineON
core:0
64.00000 67.094
core:24
64.00000 100.237
core:48
64.00000 67.614
core:72
64.00000 101.096

//从下面两组测试来看只要BIOS off了内存就会跨 node 交织，大规模测试下内存 latency 是个平均值
#grep -E "core|64.00000" lat.log.BIOSOff.cmdlineOff //BIOS off 做内存交织，latency就是平均值
core:0
64.00000 85.657  //85 恰好是最大100，最小68的平均值
core:24
64.00000 85.741
core:48
64.00000 85.977
core:72
64.00000 86.671

//BIOS 关闭后numa后，OS层面完全不知道下层的结构，默认一定是做交织
#grep -E "core|64.00000" lat.log.BIOSOff.cmdlineON
core:0
64.00000 89.123
core:24
64.00000 87.137
core:48
64.00000 87.239
core:72
64.00000 87.323

从数据可以看到在BIOS 设置ON后，无论 OS cmdline 启动参数里是否设置了 ON 还是 OFF，内存延时都是抖动且一致的(这个有点诧异，说好的消除抖动的呢？)。如果BIOS 设置OFF后内存延时是个稳定的平均值(这个比较好理解)

疑问

• 内存交错时为什么 lmbench 测试得到的时延是平均值，而不是短板效应的最慢值？ 测试软件只能通过大规模数据的读写来测试获取一个平均值，所以当一大块内存读取时，虽然通过交织大块内存被切分到了快慢物理内存上，但是因为规模大慢的被平均掉了。(欢迎内核大佬指正)
• 什么是内存交织？ 我的理解：假如你有8块物理内存条，如果你有一个int 那么只能在其中一块上，如果你有1MB的数据那么会按cacheline 拆成多个块然后分别放到8块物理内存条上(有快有慢)这样带宽更大，最后测试得到一个平均值 如果你开启numa那么只会就近交织，比如0-3号内存条在0号core所在的node，OS 做内存交织的时候只会拆分到这0-3号内存条上，那么时延总是最小的那个，如上测试中的60多纳秒。

这个问题一直困扰了我几年，所以我最近再次测试验证了一下，主要是对 BIOS=on 且 cmdline=off 时有点困扰

Intel 的 mlc 验证

测试参数: BIOS=on 同时 cmdline off 用Intel 的 mlc 验证下，这个结果有点意思，latency稳定在 145 而不是81 和 145两个值随机出现，应该是mlc默认选到了0核，对应lmbench的这组测试数据(为什么不是100.717， 因为测试方法不一样)：

//如下是前面 lmbench 测试结果，抄下来和 mlc 做个对比 
//从下面两种测试来看，BIOS层面 on后，不管OS 层面是否on，都不会跨node 做交织，抖动存在
//BIOS on 即使在OS层面关闭numa也不跨node做内存交织，抖动存在
#grep -E "core|64.00000" lat.log.BIOSON.cmdlineOff 
core:0
64.00000 100.717
core:24
64.00000 68.484
core:48
64.00000 101.070
core:72
64.00000 68.483

对应的mlc

#./mlc
Intel(R) Memory Latency Checker - v3.9
Measuring idle latencies (in ns)...
    Numa node
Numa node    0
    0   145.8  //多次测试稳定都是145纳秒

Measuring Peak Injection Memory Bandwidths for the system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using traffic with the following read-write ratios
ALL Reads     :  110598.7
3:1 Reads-Writes :  93408.5
2:1 Reads-Writes :  89249.5
1:1 Reads-Writes :  64137.3
Stream-triad like:  77310.4

Measuring Memory Bandwidths between nodes within system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
    Numa node
Numa node    0
    0  110598.4

Measuring Loaded Latencies for the system
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Inject  Latency Bandwidth
Delay (ns)  MB/sec
==========================
 00000  506.00   111483.5
 00002  505.74   112576.9
 00008  505.87   112644.3
 00015  508.96   112643.6
 00050  574.36   112701.5

当两个参数都为 on 时的mlc 测试结果：

#./mlc
Intel(R) Memory Latency Checker - v3.9
Measuring idle latencies (in ns)...
    Numa node
Numa node    0     1
    0    81.6   145.9
    1   144.9    81.2

Measuring Peak Injection Memory Bandwidths for the system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using traffic with the following read-write ratios
ALL Reads     :  227204.2
3:1 Reads-Writes :  212432.5
2:1 Reads-Writes :  210423.3
1:1 Reads-Writes :  196677.2
Stream-triad like:  189691.4

说明：mlc和 lmbench 测试结果不一样，mlc 时81和145，lmbench测试是68和100，这是两种测试方法的差异而已，但是快慢差距基本是一致的

结论

在OS 启动引导参数里设置 numa=off 完全没有必要、也不能解决抖动的问题，反而设置了 numa=off 只能是掩耳盗铃，让用户看不到 NUMA 结构

原文链接

本文为阿里云原创内容，未经允许不得转载。