1. 系统环境

OS: CentOS Linux release 7.8.2003 (Core)

Kernel: 3.10.0-1127.19.1.el7.x86_64

MySQL: 用5.0、5.7均有此问题，应该和版本无关

2. 压测工具

benchyou[1]

mysql_random_load[2]

3. 问题现象

利用 mysql_random_load 工具连接MySQL写入数据时，性能非常非常低。

由于 mysql_random_load 工具不支持通过socket连接，只好放弃，改用benchyou。顺便说一下，benchyou和sysbench极为相似，也非常好用。

改用benchyou工具后，压测正常。看来的确不是MySQL版本的问题。

用 mysql_random_load 工具进行压测时，系统负载非常高，同时可观测到系统的中断也很高并且也很不均衡。

[root@yejr.run]# vmstat -S m 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----

r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

2  0      0  73585      2  41051    0    0   117    91    4    2  0  0 99  0  0

2  0      0  73585      2  41051    0    0     0 28320 55444 100207 18  2 80  0  0

4  0      0  73584      2  41052    0    0     0  1936 52949 98607 18  2 81  0  0

2  0      0  73583      2  41052    0    0     0  4864 56375 101262 14  2 84  0  0

4  0      0  73583      2  41052    0    0     0 29064 55806 103715 19  2 80  0  0

5  0      0  73583      2  41052    0    0     0  5704 55854 98386 15  2 83  0  0

可以看到 system.in 这列的值非常高，改成benchyou工具后，这列的值从5.5万降到1.6万。

[root@yejr.run]# vmstat -S m 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----

r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

4  0      0  77238      2  38371    0    0   118    88    2    3  0  0 99  0  0

2  0      0  77234      2  38374    0    0     0 31620 16039 77988  3  2 95  0  0

2  0      0  77231      2  38377    0    0     0 31996 16091 78926  3  2 95  0  0

3  0      0  77229      2  38378    0    0     0 33028 16347 81006  3  2 95  0  0

0  0      0  77226      2  38383    0    0     0 52412 15496 75715  3  2 95  0  0

2  0      0  77224      2  38384    0    0     0 32252 16167 79352  3  2 95  0  0

再看下有问题时的系统中断表现

[root@yejr.run]# mpstat -I SUM -P ALL 1

Linux 3.10.0-1127.19.1.el7.x86_64 (yejr.run)  09/28/2020  _x86_64_ (32 CPU)

05:37:40 PM  CPU    intr/s

05:37:41 PM  all  51833.00

05:37:41 PM    0   2069.00

05:37:41 PM    1   1159.00

05:37:41 PM    2   2979.00

05:37:41 PM    3   1580.00

05:37:41 PM    4   1627.00

05:37:41 PM    5   1461.00

05:37:41 PM    6   1243.00

05:37:41 PM    7   1825.00

05:37:41 PM    8   2154.00

05:37:41 PM    9   1367.00

05:37:41 PM   10   1277.00

05:37:41 PM   11   1376.00

05:37:41 PM   12   4085.00

05:37:41 PM   13   1601.00

05:37:41 PM   14   4045.00

05:37:41 PM   15   1857.00

05:37:41 PM   16   1692.00

05:37:41 PM   17    722.00

05:37:41 PM   18    118.00

05:37:41 PM   19   1862.00

05:37:41 PM   20   1637.00

05:37:41 PM   21   1130.00

05:37:41 PM   22   1750.00

05:37:41 PM   23   1653.00

05:37:41 PM   24   1417.00

05:37:41 PM   25   1547.00

05:37:41 PM   26   1500.00

05:37:41 PM   27   1033.00

05:37:41 PM   28     20.00

05:37:41 PM   29   1683.00

05:37:41 PM   30    888.00

05:37:41 PM   31   1549.00

可以看到每秒中断总量有5.5万，但多个CPU间并不均衡。

4. 问题分析

初步认定是因为系统中断太高导致的写入性能差，并且也认定是因为多个CPU间中断不均衡导致的这个问题。

观察是都有哪些中断比较高，发现主要是 LOC 和 RES 这两个每秒的增长比较大。

[root@yejr.run]# watch -d cat /proc/interrupts

...

LOC: 2468939840 2374791518 2373834803 2373613050   Local timer interrupts

SPU:          0          0          0          0   Spurious interrupts

PMI:          0          0          0          0   Performance monitoring interrupts

IWI:   50073298   45861632   45568755   45833911   IRQ work interrupts

RTR:          0          0          0          0   APIC ICR read retries

RES: 3472920231 3022439316 2990464825 3012790828   Rescheduling interrupts

CAL:    5131479    6539715   17285454   11211131   Function call interrupts

TLB:   23094853   24045725   24230472   24271286   TLB shootdowns

TRM:          0          0          0          0   Thermal event interrupts

...

在尝试修改相关中断号绑定的CPU后(参考：SMP affinity and proper interrupt handling in Linux[3])，问题还是没有得到缓解。

后来某神秘大佬给指点了下，才发现原来是个内核的bug，涉及到参数 kernel.timer_migration，需要将其设置为 0 才行。

[root@yejr.run]# sysctl -w kernel.timer_migration=0

当然了，最好持久化写入到 /etc/sysctl.conf 文件中。

[root@yejr.run]# cat /etc/sysctl.conf

kernel.timer_migration=0

#加载配置文件使之生效

[root@yejr.run]# sysctl -p

再次用 mysql_random_load 工具进行压测就没事了。

下面是关于该bug的描述

The bug is when linux os receive too many tcp packages,

and the tcp may add too many timer, but in

get_target_base->get_nohz_timer_target it check current

cpu is idle, sometimes thouth the current core is very busy,

but the idle_cpu result is 1, in this time

if set kernel.timer_migration=1 ,the timer will be move to next cpu.

bug详情见：Bug 124661 - kernel.timer_migration=1 cause too many Rescheduling interrupts[4]

最后，值得一提的是，在云主机上修改该参数应该是不管用，除非修改物理机的。我在某云主机上运行 mysql_random_load 工具压测也遇到类似问题，修改内核参数后问题依旧。

文内链接

[1]:https://github.com/xelabs/benchyou

[2]:https://github.com/Percona-Lab/mysql_random_data_load

[3]:http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux

[4]:https://bugzilla.kernel.org/show_bug.cgi?id=124661

全文完。

Enjoy Linux & MySQL :)

「MySQL核心优化」课已升级到MySQL 8.0，扫码开启MySQL修行之旅