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

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 写这个续篇是我收到很多解释,因为跨Node 导致性能抖动,所以集团在物理机OS 的启动参数里设置了 numa=off ,也就是不管BIOS 中如何设置,我们只要在OS 层面设置一下 numa=off 就能让程序稳定下来不再抖了! 我这几年也认为这是对的,只是让我有点不理解,既然不区分远近了,那物理上存在的远近距离(既抖动)如何能被消除掉的呢? 所以这个续篇打算通过测试来验证下这个问题

背景


十年后数据库还是不敢拥抱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和引导参数各有两种设置方式,组合起来就是四种,我们分别设置并跑一下内存时延,测试结果:


09362abb105e0a5b36f5e76b12fff6e1.png


测试原始数据如下(测试结果文件名 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 结构




数据库PolarDB-X新人入门一站式页面,快速体验集中分布式一体化新特性!


云原生数据库PolarDB分布式版新人入门

相关实践学习
Polardb-x 弹性伸缩实验
本实验主要介绍如何对PolarDB-X进行手动收缩扩容,了解PolarDB-X 中各个节点的含义,以及如何对不同配置的PolarDB-x 进行压测。
相关文章
|
6天前
|
存储 运维 关系型数据库
数据的力量:构筑现代大型网站之数据库基础与应用
数据的力量:构筑现代大型网站之数据库基础与应用
176 0
|
1月前
|
分布式数据库 数据库 数据安全/隐私保护
开发者关注的数据库技术与创新,未来数据库的演进及理想数据库的构想
作为开发者,想必大家都知道在技术圈中数据库相关领域是技术开发中的重中之重,数据库技术与创新不断推动着数字化时代的发展,数据库技术正在经历着一次创新的浪潮,还有就是数据库技术的不断创新为开发者们在日常实际开发中提供了更多的可能性和好的机遇。那么本文就来简单聊聊最值得开发者关注的数据库技术与创新,包括分布式数据库、图数据库、时序数据库、区块链数据库以及AI与数据库的结合等方面,以及探讨未来数据库的演进趋势,并讨论一下在开发者心目中最理想的数据库的特征与构想。
43 3
|
2天前
|
存储 安全 区块链
未来数据库技术发展趋势探析
【2月更文挑战第3天】 随着信息时代的快速发展,数据库技术作为信息存储和管理的核心工具,在不断演进与创新。本文将从人工智能、区块链、云计算等角度切入,探讨未来数据库技术的发展趋势,展望数据库技术的前景。
|
2天前
|
存储 NoSQL 数据管理
现代数据库技术发展趋势与应用前景探析
【2月更文挑战第2天】 随着信息时代的快速发展,数据库技术作为信息存储和管理的核心工具也在不断演进。本文将就当前现代数据库技术的发展趋势及其在实际应用中的前景进行探讨,旨在帮助读者更好地了解数据库技术的最新动向。
|
2月前
|
存储 Oracle 关系型数据库
“多写多读集群”被攻克,中国数据库产业“越过山丘”
在自主创新的道路上默默苦行了十几年的中国数据库产业,正在越过山丘,等待他们的,将是一个繁荣的数据库生态。
|
6月前
|
关系型数据库 分布式数据库 数据库
云原生时代下的国产开源数据库是如何实现更多的技术创新和突破?听听他们怎么说
大咖云集,燃爆夏日。8月5日,由PostgreSQL中文社区、阿里云PolarDB开源社区、蚂蚁OceanBase开源社区联合举办的开源数据库技术沙龙在杭州召开,来自PG中文社区、阿里云PolarDB、蚂蚁集团、OceanBase等专家大咖全方位解读了国产数据库核心技术与架构、时下成熟的解决方案及最佳实践,并与高校、伙伴探讨了如何推动产教结合,加快国产数据库核心人才培养。近百位业内专家与开源技术爱好者、资深开发者们齐聚一堂,共话开源数据库技术与人才培养。
云原生时代下的国产开源数据库是如何实现更多的技术创新和突破?听听他们怎么说
|
9月前
|
SQL 人工智能 Cloud Native
云原生数据库的新时代,藏在“四化”当中
云原生数据库的新时代,藏在“四化”当中
|
Cloud Native Serverless 双11
|
存储 Cloud Native NoSQL
赛题解析 | 第四届全球数据库大赛——赛道1: 云原生共享内存数据库性能优化
第四届全球数据库大赛—PolarDB性能挑战赛,瓜分40万奖金池,只等你来!各赛道TOP10都可获得现金奖励
622 0
赛题解析 | 第四届全球数据库大赛——赛道1: 云原生共享内存数据库性能优化
|
人工智能 Oracle Cloud Native
8月2日19:30 | 李飞飞、盖国强、李国良与您共论数据库技术的演进与趋势
三位大咖聚首,聊一聊数据库技术的演进历程与趋势。
1194 0
8月2日19:30 | 李飞飞、盖国强、李国良与您共论数据库技术的演进与趋势

热门文章

最新文章

相关产品

  • 云原生分布式数据库 PolarDB-X
  • http://www.vxiaotou.com