关于mysql:技术分享-浅谈-NUMA-与-MySQL

10次阅读

共计 2484 个字符，预计需要花费 7 分钟才能阅读完成。

作者：孙祚龙

爱可生南区交付服务部团队 DBA，负责客户 MySQL 的故障解决以及我司数据库集群治理平台 DMP 的日常运维。

本文起源：原创投稿

* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

该问题来自于在给客户部署 MySQL 前进行服务器环境配置时，波及到服务器配置项敞开 numa，客户对此配置项的必要性产生了疑虑。针对这一疑虑，进行了以下对于 numa 的钻研。

NUMA（Non-Uniform Memory Access，非一致性内存拜访）
NUMA 服务器的基本特征是 Linux 将零碎的硬件资源划分为多个软件形象，称为节点（Node），每个节点上有独自的 CPU、内存和 I/O 槽口等。CPU 拜访本身 Node 内存的速度将远远高于拜访远地内存（零碎内其它节点的内存）的速度，这也是非统一内存拜访 NUMA 的由来。

NUMA 的 4 种内存调配策略：

缺省（default）：总是在本地节点调配（以后过程运行的节点上）
绑定（bind）：强制调配到指定节点上
穿插（interleavel）：在所有节点或者指定节点上穿插分配内存
优先（preferred）：在指定节点上调配，失败则在其余节点上调配

NUMA 的内存调配策略对于过程来说，并不是乐观的。因为 NUMA 默认是应用 CPU 亲和的内存调配策略，即申请过程会从以后所处的 CPU 的 Node 申请分配内存。当某个须要耗费大量内存的过程耗尽了所处的 Node 的内存时，就会导致产生 swap，不会从近程 Node 分配内存，这就是 swap insanity 景象。

MySQL 数据库是单过程多线程的架构，在开启的 NUMA 服务器中，内存被调配到各 NUMA Node 上，而 MySQL 过程只能耗费所在节点的内存。所以在开启 NUMA 的服务器上，某些非凡场景中容易呈现零碎领有闲暇内存但产生 SWAP 导致性能问题的状况。

比方专用的 MySQL 单实例服务器，物理内存为 40GB，MySQL 过程所在节点的本地内存为 20G，而 MySQL 配置 30GB 内存，超出节点本地内存局部会被 SWAP 到磁盘上，而不是应用其余节点的物理内存，引发性能问题。

1. 硬件层，在 BIOS 中设置敞开；

2. OS 内核层，在 Linux Kernel 启动参数中加上 numa=off 后重启服务器；

For RHEL 6：

编辑 /boot/grub/grub.conf 文件的 kernel 行（增加 numa=off）：

# vi /boot/grub/grub.conf
kernel /vmlinuz-2.6.39-400.215.10.EL ro root=/dev/VolGroup00/LogVol00 numa=off

For RHEL 7：

编辑 /etc/default/grub 文件的 kernel 行

# vi /etc/default/grub
GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel_vm-210/root rd.lvm.lv=rhel_vm-210/swap vconsole.font=latarcyrheb-sun16 crashkernel=auto  vconsole.keymap=us rhgb quiet numa=off

RHEL7/CentOS7 必须要重建 GRUB 配置文件能力失效：

# grub2-mkconfig -o /etc/grub2.cfg

3. 数据库层，在 mysqld_safe 脚本中加上“numactl –interleave all”来启动 mysqld。

# numactl --interleave=all ./bin/mysqld_safe --defaults-file=/etc/my.cnf &

MySQL 在 5.6.27、5.7.9 引入了 innodb_numa_interleave 参数，MySQL 本身解决了内存分类策略的问题，须要服务器反对 numa。

依据官网文档的形容：

当启用 innodb_numa_interleave 时，mysqld 过程的 NUMA 内存策略被设置为 MPOL_INTERLEAVE；InnoDB 缓冲池调配结束后，NUMA 内存策略又被设置为 MPOL_DEFAULT。当然 innodb_numa_interleave 参数失效，MySQL 必须是在启用 NUMA 的 Linux 零碎上编译装置。从 MySQL 5.7.17 开始，CMake 编译软件新增了 WITH_NUMA 参数，能够在反对 NUMA 的 Linux 零碎上编译 MySQL。须要留神 innodb_numa_interleave 参数在 MySQL5.7.17 的二进制包中是不反对的。

通过测试：

1. 零碎若不反对 numa，-DWITH_NUMA=ON 会导致 CMake 编译失败；

2.MySQL5.7.19+ 的免编译的二进制包开始反对 innodb_numa_interleave 参数。

若是专用的 MySQL 服务器，能够敞开间接在 BIOS 层或者 OS 内核层敞开 NUMA；

若心愿其余过程应用 NUMA 个性，能够抉择适合的 MySQL 版本开启 innodb_numa_interleave 参数。

对于 NUMA 的小误区：

numactl 命令未找到，numa 就是未开启吗？

不是，numactl 是 Linux 提供的一个对 NUMA 进行手工调优的命令（默认不装置），能够用 numactl 命令查看零碎的 NUMA 状态和对 NUMA 进行管制。

参考资料：

“The MySQL“swap insanity”problem and the effects of the NUMA architecture”：

https://blog.jcole.us/2010/09…

“A brief update on NUMA and MySQL”：
https://blog.jcole.us/2012/04…

https://www.kernel.org/doc/ht…

http://mysql.taobao.org/month…

https://www.thegeekdiary.com/…

正文完