数据库内核月报 - 2015 / 07

MySQL · 社区动态 · MySQL内存分配支持NUMA

NUMA 问题曾经一直是困扰DBA的一个大问题,早在 2010 年, 就有人给MySQL报了Bug#57241, 指出了MySQL在x86系统下存在严重的 “swap insanity” 问题。在NUMA架构越来越普遍的今天,这个问题越来越严重。

MySQL的 swap insanity 问题

有同学专门翻译了Jeremy Cole关于 “swap insanity” 问题的文章,原文看这里

如果你没空看的话,这里简单描述一下,就是当你把主机大部分内存分配给InnoDB时,你会发现明明操作系统还有很多内存,但是却有很多内存被交换到了SWAP分区。

这里可以下载到一个测试的C代码,如果你有NUMA架构的服务器,可以测试下不同分配方式的性能差异:

sudo -s
echo 2048 > /proc/sys/vm/nr_hugepages
echo 1000000000000 > /proc/sys/kernel/shmmax

# Node local allocation
for i in `seq 0 4 127`
do
./latency2001 -a $i -c $i -l 128M
done

# Allocate on memory on CPU 0
for i in `seq 0 4 127`
do
./latency2001 -a 0 -c $i -l 128M
done

有两个方式可以解决这个问题:
1. 在Linux Kernel启动参数中加上numa=off(这样也会影响到其他进程使用NUMA);
2. 在mysqld_safe脚本中加上“numactl –interleave all”来启动mysqld。

当然如果跑多实例,我也用过直接绑定mysqld进程到某个numa节点的方式,不过这要求每个实例分配的内存不超过每个NUMA节点管理的内存。脚本可以看这里

5年过去了,官方依然没有解决这个Bug。但好消息是,官方终于着手解决这个问题了,Stewart Smith 同学提交的Bug#72811,其Patch即将出现在MySQL 5.6.27, 5.7.9 版本之中。

代码层面解决NUMA问题

如果在代码层面彻底解决NUMA问题,那么我们需要解决两个问题:
1. 全局内存应该采用interleave的分配方式分散在不同的numa node上;
2. 线程内存应该采用local的分配方式分配在线程运行的numa node上。

Linux 提供了 set_mempolicy() 函数可以用来设置进程的内存分配策略,其中默认的MPOL_DEFAULT策略就是在当前运行的节点上分配内存,而MPOL_INTERLEAVE策略则是跨所有节点来分配内存。这个函数的说明可以看这里

因此对于MySQL Server和InnoDB引擎都需要做修改:
1. 在mysqld_main()入口设置 set_mempolicy(MPOL_INTERLEAVE, NULL, 0) 启用全局分配方式;
2. 在MySQL启动完成之后设置set_mempolicy(MPOL_DEFAULT, NULL, 0) 启用本地分配方式;
3. 在InnoDB入口时设置 set_mempolicy(MPOL_INTERLEAVE, NULL, 0) 启用全局分配方式;
4. 在Buffer Pool分配完成时设置 set_mempolicy(MPOL_DEFAULT, NULL, 0) 启用本地分配方式。

MySQL 5.6.27, 5.7.9 发布之后,将会增加一个 innodb_numa_interleave 参数来控制这个策略。innodb_numa_interleave 如果打开,那么将会按上面的策略来设置内存分配方式,如果关闭或者主机不支持NUMA,那么还是按原来的方式分配。

我们一起期待新版本的发布吧,妈妈再也不用担心我的NUMA了!