MySQL--NUMA与MySQL

=============================================================

NUMA(Non-Uniform Memory Access)，非一致性内存访问
NUMA服务器的基本特征是具有多个CPU模块，每个CPU模块由多个CPU(如4个)组成，并且具有独立的本地内存、I/O槽口等。由于其节点之间可以通过互联模块(如称为Crossbar Switch)进行连接和信息交互，因此每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要差别)。显然，访问本地内存的速度将远远高于访问远地内存(系统内其它节点的内存)的速度，这也是非一致存储访问NUMA的由来。
利用NUMA技术，可以较好地解决原来SMP系统的扩展问题，在一个物理服务器内可以支持上百个CPU。但NUMA技术同样有一定缺陷，由于访问远地内存的延时远远超过本地内存，因此当CPU数量增加时，系统性能无法线性增加。

=============================================================

查看CPU和MUMA的拓扑信息

numactl --hardware

上面是2U服务器，配置64G内存

=============================================================

MySQL与NUMA问题

在单实例的MySQL服务器上，通过会为MySQL的Buffer Pool分配50%至70%甚至更高的内存，让MySQL 服务会尽可能多地占用系统资源。在基于NUMA系统中，内存被分配到各NUMA节点上，系统的默认为进程分配该进程所在NUMA节点的内存，而数据库应用又希望使用到所有CPU节点和内存，由于MySQL对NUMA支持不是很完善，在特殊场景中容易出现系统拥有空闲内存但发生SWAP导致性能问题的情况。

如对于2个NUMA节点64GB内存的MySQL服务器来说，为MySQL Buffer Pool配置48GB的内存，在默认NUMA策略下，会存在以下问题：
1、节点0和节点1的内存分配不平衡，内存会优先分配给节点0，节点1被用于备份，如：

2、当属于节点0的内存完全分配给节点0，如果位于NODE0上的进程调度需要大量内存，尽管节点1仍有大量空闲物理内存，也不会将NODE1上的内存分配给该进程使用，由于节点0已无空闲内存，因此会导致NODE0上部分内存被SWAP到磁盘上，引发性能问题。

=============================================================

为MySQL关闭NUMA

在MUMA架构下，虽然访问其他节点内存的性能低于访问本地节点内存，但并不是导致性能问题的主要原因，为解决系统存在空闲内存而部分NUMA发生SWAP操作的问题.

解决方式：

1、在BIOS层关闭NUMA
2、在Linux Kernel启动参数中加上numa=off（这样也会影响到其他进程使用NUMA）；
3、在mysqld_safe脚本中加上“numactl –interleave all”来启动mysqld。

参数--interleave=nodes用于设定内存的交织分配模式，即系统在为多个节点分配内存空间时，将以轮询分发的方式分配给多个节点，如果当前众多的交织分配内存节点中的目标节点无法正确地分配内存空间的话，内存空间将会由其他节点来分配。

修改后MySQL内存分配如：

=============================================================

参考资料：
http://mysql.taobao.org/monthly/2015/07/06/
http://linux.51yip.com/search/numactl
http://sohulinux.blog.sohu.com/181968823.html
http://imysql.com/2016/11/30/mysql-faq-find-who-cause-mysql-swap.shtml?utm_source=tuicool&utm_medium=referral

=============================================================