MySQL高阶讲座之：`MySQL`的`NUMA`架构优化：如何配置`Memory`和`CPU`以减少跨`Node`访问。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众老爷们，大家好！我是今天的主讲人，江湖人称“MySQL小钢炮”。今天咱们来聊聊一个听起来高大上，但其实琢磨透了也没那么玄乎的玩意儿：MySQL的NUMA架构优化。

这玩意儿，说白了，就是想让你的MySQL跑得更快、更稳，避免出现“远距离恋爱”的悲剧。啥意思？别急，咱们慢慢唠。

一、啥是NUMA？别跟我拽英文，说人话！

想象一下，你的电脑是个大型的“联合国”，里面有很多“国家”（Node）。每个“国家”都有自己的“资源”（CPU、内存），但是整个“联合国”共享所有资源。

UMA (Uniform Memory Access)： 以前的老电脑，就像一个“大锅饭”时代，所有CPU想访问内存，都得通过同一个“通道”。CPU之间没有亲疏远近，访问内存的速度都差不多。这种架构简单粗暴，但效率不高。
NUMA (Non-Uniform Memory Access)： 现在的服务器，聪明多了！它把CPU和内存分成一个个的“小集团”（Node）。每个Node里的CPU访问自己Node里的内存，速度飞快。但是，如果一个Node里的CPU要访问另一个Node里的内存，那就得“跨国访问”，速度慢得多。

所以，NUMA的核心思想就是：尽量让CPU访问离自己最近的内存！ 这样才能减少“跨国访问”，提高整体性能。

二、MySQL和NUMA：天生一对，但得好好调教

MySQL很喜欢多核CPU，也喜欢大内存。但是，如果你不告诉MySQL怎么好好利用NUMA架构，它就会像个熊孩子一样，乱用资源，反而降低性能。

举个例子：你有一台双路服务器，每个路（Node）有16个CPU核心和64GB内存。MySQL启动后，如果没有特别配置，它可能会在Node 0上分配了所有的线程和内存。这样Node 1上的CPU就只能眼巴巴地看着Node 0的内存，想用还得“跨国访问”，你说冤不冤？

三、NUMA架构下，MySQL的常见问题：

内存分配不均衡： 所有的MySQL线程都在一个Node上分配内存，导致该Node内存压力过大，而其他Node闲置。
CPU利用率不均衡： 某些Node的CPU负载很高，而其他Node的CPU却很空闲。
跨Node访问频繁： CPU频繁访问其他Node的内存，导致延迟增加，性能下降。

四、NUMA优化大法：让MySQL和NUMA“喜结连理”

想要让MySQL在NUMA架构下发挥最大威力，我们需要做一些“牵线搭桥”的工作。主要分为以下几个步骤：

查看NUMA信息：摸清家底

首先，我们要搞清楚服务器的NUMA架构，看看有几个Node，每个Node有多少个CPU核心和内存。

在Linux系统下，可以使用 numactl --hardware 命令查看：
```
numactl --hardware
```
输出结果类似：
```
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 65463 MB
node 0 free: 63231 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 65536 MB
node 1 free: 63456 MB
```
从上面的输出可以看出，这台服务器有两个Node（0和1），每个Node有16个CPU核心和64GB内存。
绑定MySQL进程到指定的NUMA Node：划清界限

最简单粗暴的方法，就是把MySQL进程绑定到指定的NUMA Node上。这样可以保证MySQL进程的所有线程都在该Node上运行，避免跨Node访问。

可以使用 numactl --cpunodebind=<node_id> --membind=<node_id> <command> 命令来实现：
```
numactl --cpunodebind=0 --membind=0 /usr/sbin/mysqld --defaults-file=/etc/mysql/my.cnf
```
这条命令的意思是：把mysqld进程绑定到Node 0上，并且只允许在Node 0上分配内存。

注意： 这种方法虽然简单，但是不够灵活。如果Node 0的负载过高，而Node 1却很空闲，那就浪费了资源。
配置innodb_numa_affinity参数：精细化管理

MySQL 5.6及以上版本提供了一个 innodb_numa_affinity 参数，可以更精细地控制InnoDB线程和内存的分配。

这个参数可以设置为以下几种值：
- OFF：禁用NUMA优化。
- ON：启用NUMA优化，InnoDB会尝试将线程和内存分配到离自己最近的NUMA Node上。
- <node_id>：指定InnoDB线程和内存分配到指定的NUMA Node上。
可以在MySQL的配置文件（my.cnf）中设置这个参数：
```
[mysqld]
innodb_numa_affinity=ON
```
注意： 启用 innodb_numa_affinity 参数后，InnoDB会根据服务器的NUMA架构，自动调整线程和内存的分配。但是，这个参数并不能保证完全避免跨Node访问，只能尽量减少。
调整线程池大小：避免线程过多

线程池大小也会影响NUMA性能。如果线程池过大，会导致线程在不同的Node之间频繁切换，增加跨Node访问的概率。

建议根据服务器的CPU核心数和内存大小，合理调整线程池大小。

可以使用以下参数来调整线程池大小：
- innodb_read_io_threads：InnoDB读IO线程数。
- innodb_write_io_threads：InnoDB写IO线程数。
- innodb_buffer_pool_size：InnoDB缓冲池大小。
例如：
```
[mysqld]
innodb_read_io_threads=8
innodb_write_io_threads=8
innodb_buffer_pool_size=32G
```
注意： 线程池大小需要根据实际情况进行调整，不能一概而论。
使用Performance Schema监控NUMA性能：实时监控

MySQL的Performance Schema提供了一些表，可以用来监控NUMA性能。
- memory_summary_global_by_event_name：可以查看每个内存事件的分配情况，包括NUMA Node信息。
- threads：可以查看每个线程的CPU亲和性。
例如，可以使用以下SQL语句查看InnoDB缓冲池在各个NUMA Node上的分配情况：
```
SELECT
   EVENT_NAME,
   SUM(CURRENT_NUMBER_OF_BYTES_USED) AS total_bytes
FROM
   performance_schema.memory_summary_global_by_event_name
WHERE
   EVENT_NAME LIKE 'memory/innodb/buf_buf%'
GROUP BY
   EVENT_NAME
ORDER BY
   total_bytes DESC;
```
注意： 使用Performance Schema会增加一定的性能开销，建议只在需要监控NUMA性能时启用。

五、实战演练：一个完整的NUMA优化方案

假设我们有一台双路服务器，每个路（Node）有16个CPU核心和64GB内存。我们希望优化MySQL的NUMA性能。

查看NUMA信息：

numactl --hardware

输出结果：

available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 65463 MB
node 0 free: 63231 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 65536 MB
node 1 free: 63456 MB

配置MySQL：

在MySQL的配置文件（my.cnf）中添加以下内容：
```
[mysqld]
innodb_numa_affinity=ON
innodb_read_io_threads=16
innodb_write_io_threads=16
innodb_buffer_pool_size=64G
innodb_buffer_pool_instances=16
```
- innodb_numa_affinity=ON：启用NUMA优化。
- innodb_read_io_threads=16：设置InnoDB读IO线程数为16，每个Node 8个线程。
- innodb_write_io_threads=16：设置InnoDB写IO线程数为16，每个Node 8个线程。
- innodb_buffer_pool_size=64G：设置InnoDB缓冲池大小为64GB，每个Node 32GB。
- innodb_buffer_pool_instances=16：将缓冲池分为16个实例，尽量让每个线程访问离自己最近的缓冲池实例。
重启MySQL：
```
systemctl restart mysqld
```
监控NUMA性能：

使用Performance Schema监控NUMA性能，查看内存分配和CPU利用率是否均衡。

六、总结：NUMA优化，任重道远

NUMA优化是一个复杂的过程，需要根据实际情况进行调整。没有一劳永逸的解决方案，只有不断地尝试和优化。

希望今天的讲座能帮助大家更好地理解NUMA架构，并能应用到实际的MySQL优化中。记住，只有不断学习，才能成为真正的“MySQL小钢炮”！

七、一些额外的Tips：

操作系统层面： 确保操作系统也支持NUMA架构，并且已经正确配置。
硬件层面： 选择支持NUMA架构的服务器，并且确保CPU和内存的配置合理。
监控和调优： 定期监控MySQL的NUMA性能，并根据实际情况进行调整。

好了，今天的讲座就到这里。感谢大家的观看！如果大家有什么问题，可以在评论区留言，我会尽力解答。咱们下次再见！

发表回复 取消回复

发表回复取消回复