从服务器架构说起

我们先来看一下服务器多CPU架构的变迁过程，一开始是单CPU，后来发展到双CPU或者多CPU的SMP架构，也就是多CPU共享相同的内存、总线、操作系统等资源，每个CPU访问全局内存任何地址耗费的时间都是相等的。还有一类AMP架构，即不同的CPU做的事情是不同的。但是由于共享访问的冲突，SMP架构扩展性-效率曲线已经达到瓶颈。

为了进一步提高CPU数量同时保证效率，NUMA架构出现了，也就是将多个SMP进行松一点的耦合，多个SMP之间通过CrossBar Switch 告诉交换矩阵互联，每个SMP都各有各自的内存，一个SMP内部的CPU访问自己的内存和之前没什么两样，但是要访问其它SMP处的内存，就需要走交换矩阵，导致延迟增加，所以，NUMA通过牺牲了内存访问的时延来达到更高的扩展性，比如将数百个CPU组成NUMA架构。SMP和NUMA架构对于软件程序方面的影响不大，同一台主机内都是用单一操作系统。但是由于NUMA访问远端内存时的时延问题，导致NUMA架构下的效率也不能随着CPU数量的增加而线性增长，只是比SMP好一些罢了。

其实，如果在NUMA架构下，软件也可以避免尽量少读取源端内存的话，那么NUMA效率也会线性增长，但是NUMA架构下的操作系统仍然是同一个，内存仍然是全局均匀的，而程序架构又尽量保持不变，那么就不可避免的是不是访问远端内存了。

以下时UMA和NUMA的架构图。

NUMA 与数据库应用

在数据库应用来说， NUMA 共享内存系统上运行的一种方法是忽略内存访问的非一致性。 只要不均匀性很小，这种方法就可以接受。 当近内存与远内存访问时间的比率超过 1.5:1 到 2:1 范围时，就会出现严重的内存访问瓶颈。 要避免这个问题，由两种基本方法：

a. 当分配内存供处理器使用时，使用该处理器的本地内存（避免使用远内存）。

b. 如果可能的话，worker 总是被安排在它之前所在的同一硬件处理器上。 这种组合允许 DBMS 工作负载在内存访问时间不一致的大规模共享内存系统上运行良好。

当然这两点都取决于数据库的设计。以上讨论都是基于忽略内存访问非一致性，尽量使用的数据都在本地内存中，而这在显然是不可控的。

一些数据库在设计实现对NUMA架构做了优化，可以感知NUMA拓扑来动态调整线程和内存分配，从而减少远程内存访问。目前查阅DM的文档还没有对NUMA架构的优化项，期待未来会有。对于单进程多线程的DM来说，对于共享内存的依赖会大些，所以在生产环境中是建议关闭的。

想象这样一个场景，用户说我有一个128C 512G 的服务器，想把DM数据库放上面，需要高并发下性能要好些。数据库需要关闭NUMA，退回到SMP架构，但是SMP架构会由于共享访问冲突CPU和内存无法得到充分利用，显然是有些浪费了。这个时候就可以考虑类似Oracle数据库的RAC架构了，因为用两台64C 256G 的 RAC 会比一台128C 512G的服务器性能更好，而且资源可以得到充分利用。

NUMA开启与关闭测试对比

基础环境信息

numa_node	
NUMA node0 CPU(s):               0-7	64-71
NUMA node1 CPU(s):               8-15	72-79
NUMA node2 CPU(s):               16-23	80-87
NUMA node3 CPU(s):               24-31	88-95
NUMA node4 CPU(s):               32-39	96-103
NUMA node5 CPU(s):               40-47	104-111
NUMA node6 CPU(s):               48-55	112-119
NUMA node7 CPU(s):               56-63	120-127

#缓存
L1d cache:                       2 MiB
L1i cache:                       4 MiB
L2 cache:                        32 MiB
L3 cache:                        128 MiB

#内存分配和NUMA拓扑
[dmdba@cxcp05 ~]$ numactl --hardware
available: 8 nodes (0-7)
node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
node 0 size: 63974 MB
node 0 free: 21699 MB
node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
node 1 size: 64476 MB
node 1 free: 50571 MB
node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
node 2 size: 64507 MB
node 2 free: 38692 MB
node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
node 3 size: 64507 MB
node 3 free: 42954 MB
node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 102 103
node 4 size: 64507 MB
node 4 free: 47101 MB
node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109 110 111
node 5 size: 64507 MB
node 5 free: 38380 MB
node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117 118 119
node 6 size: 64507 MB
node 6 free: 46671 MB
node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125 126 127
node 7 size: 63483 MB
node 7 free: 48231 MB
node distances:
node   0   1   2   3   4   5   6   7 
  0:  10  16  16  16  28  28  22  28 
  1:  16  10  16  16  28  28  28  22 
  2:  16  16  10  16  22  28  28  28 
  3:  16  16  16  10  28  22  28  28 
  4:  28  28  22  28  10  16  16  16 
  5:  28  28  28  22  16  10  16  16 
  6:  22  28  28  28  16  16  10  16 
  7:  28  22  28  28  16  16  16  10 

测试结果

NUMA ON

NUMA OFF

图表分析

结合图标分析可知，100并发时，NUMA开启性能会更好些，这是因为并发低数据冲突的概率就会小些，加上SMP架构本身内存访问也是有瓶颈的，所以NUMA架构会稍微好些。但是随着并发增加，NUMA关闭性能会更好些，也就是说，并发数多时内存访问数据冲突的概率会更大，远程内存访问会影响性能。

最后，如有不当之处，欢迎交流，共同进步！

参考资料

《大话存储》冬瓜哥著

简单聊聊数据库与NUMA - 墨天轮 (modb.pro)

《Architecture of a Database System》，Joseph M. Hellerstein1, Michael Stonebraker2 and James Hamilton3