NUMA对MySQL InnoDB的性能影响

4tr32

NUMA架构的CPU下,一个CPU有多个核心,那么每个CPU成为一个NODE
关闭这个特性时
一个NODE 使用自己的本地内存,而尽量不去访问其他NODE的内存,除非本地内存满了

Linux 如何处理NUMA架构
1 把处理器分到节点(NODE),现代处理器一般是每个节点一个处理器,一个处理器上多个核

2 为每个节点连接每个处理器的本地内存模块

3 计算节点间的沟通成本(节点距离)

通过numactl --hardware 命令可以看到Linux如何识别NUMA架构层
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39
node 0 size: 65512 MB
node 0 free: 2146 MB
node 1 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47
node 1 size: 65536 MB
node 1 free: 96 MB
node 2 cpus: 16 17 18 19 20 21 22 23 48 49 50 51 52 53 54 55
node 2 size: 65536 MB
node 2 free: 32362 MB
node 3 cpus: 24 25 26 27 28 29 30 31 56 57 58 59 60 61 62 63
node 3 size: 65536 MB
node 3 free: 21805 MB
node distances:
node   0   1   2   3
  0:  10  11  11  11
  1:  11  10  11  11
  2:  11  11  10  11
  3:  11  11  11  10

内存是平均分配到每个节点的

# Linux 如何处理资源分配
每个进程和线程继承父亲的NUMA策略.这个策略可以基于每个线程修改.
策略定义了一个进程允许被哪个节点甚至那个核心调度.

每个线程最初配分派给最"适合"的节点运行.线程也可以在其他地方运行,但是调度器试图确保现场运行在最优节点

默认情况下,内存的分配被指派到特定的节点上,即这个线程"当前"运行的节点.
在UMA/SMP 架构下,内存是平等对待的,而在NUMA下,分配其他节点的内存意味着cache的延迟和性能的下降

内存一旦分配到一个节点上,就不会移动到另一个节点,不管系统的需求,它会永远呆在那个节点上.

任何进程的NUMA策略可以被修改,通过numactl作为程序的封装,也可以使用 libnuma 编写代码管理NUMA策略.

例如使用numactl作为程序的封装:
1 使用指定策略分配内存:
     使用"当前"节点,--localalloc参数指定,这是默认的模式
     优先使用一个节点,但也可以使用其他节点,--preferred=node参数
     永远使用一个节点或一组节点, --membind=nodes
     交叉,轮询所有节点 --interleaved=all 或者 --interleaved=nodes
2 程序运行节点的选择
    指定节点(--cpunodebind=nodes) 或者 一个核心或一组核心 (--physcpubind=cpus)

NUMA 对 MySQL 和 InnoDB 的意义

对于InnoDB和大多数数据库服务器(如Oracle),他们在Linux上的工作方式是,巨大的单一进程,带有多线程.
在NUMA架构下,内存被分派到不同的节点上,当你分配了系统50%以上的内存给一个进程,这就不是一个节点内能完成的事情了.

当不同的查询同时运行时,每个处理器都无法优先地去访问一个特定查询需要内存

事实证明这是一个很重要的问题.通过/proc/pid/numa_maps可以看到mysqld分配的所有内存,你会发现一个有趣的现象

如果你查找anon=size的值,

这是其中一行的值
7ecf14000000 default anon=3584 dirty=3584 active=1024 N1=3584

7ecf14000000  虚拟内存地址
default    NUMA 策略
anon=number  匿名页面的数量
dirty  脏页,被修改的页
通常分配给进程的页总是使用的,因此都是脏的,但是由于fork,进程会有很多copy-on-write的页面的映射,他们不是脏的
swapcache=number
active  这个列出现,表示多少页面出现在活动列表,同时意味着还有一些不活跃的页面,它们将要被swapper换页出去
N0 and N1 每个节点的页面

通过一个脚本,可以统计出所有内存的情况

perl /data0/script/numa-maps-summary.pl < /proc/4417/numa_maps
N0        :       392133 (  1.50 GB)
N1        :       792466 (  3.02 GB)
N2        :       531028 (  2.03 GB)
N3        :      3743392 ( 14.28 GB)
active    :      4314131 ( 16.46 GB)
anon      :      5457149 ( 20.82 GB)
dirty     :      5456665 ( 20.82 GB)
mapmax    :          268 (  0.00 GB)
mapped    :         1930 (  0.01 GB)
swapcache :          484 (  0.00 GB)

读取/proc/pid/numa_maps的信息会阻塞进程
http://blog.wl0.org/2012/09/chec ... client-connections/


不但是mysql 还有mangodb
根据官方文档的解释，Linux, NUMA, MongoDB 这三者不是很和谐，如果当前硬件是 NUMA 的，可以把它给关了:
# numactl --interleave=all sudo -u mongodb mongod --port xxx  --logappend --logpath yyy --dbpath zzz
(vm.overcommit_ratio = 100, vm.overcommit_memory = 2)

vm.zone_reclaim_mode 设置为 0。
系统给 NUMA node 分配内存，如果 NUMA node 已经满了，这时候，系统会为本地的 NUMA node 回收内存而不是将多出来的内存给 remote NUMA node，这样整体的性能会更好，但是在某些情况下，给 remote NUMA node 分配内存会比回收本地的 NUMA node 更好，这时候就需要将 zone_reclaim_mode 给关闭了


numactl --interleave all