jbd2/dm-0-8占用CPU的问题分析与解决

0x00 问题的发现

有一台流媒体服务器，运行的是VOD服务，在并发上升时服务器的CPU load average 持续上升。在查找原因的过程中发现，top 里的 wa 也比较高，问题的原因可能是IO效率降低；

0x01 iotop 查找占用IO的进程

 [root@ubuntu ~]# iotop

Total DISK READ :       0.00 B/s | Total DISK WRITE :     7.74 M/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:     6.97 M/s
TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
535 be/3 root        0.00 B/s    0.00 B/s  0.00 % 95.80 % [jbd2/dm-0-8]
1826 be/4 mysql       0.00 B/s   22.19 K/s  0.00 %  1.18 % mysqld
1630 be/4 mysql       0.00 B/s  162.72 K/s  0.00 %  0.07 % mysqld
1632 be/4 mysql       0.00 B/s  177.51 K/s  0.00 %  0.07 % mysqld
1631 be/4 mysql       0.00 B/s  147.93 K/s  0.00 %  0.03 % mysqld
1629 be/4 mysql       0.00 B/s   88.76 K/s  0.00 %  0.03 % mysqld
1633 be/4 mysql       0.00 B/s  147.93 K/s  0.00 %  0.03 % mysqld

发现 [jbd2/dm-0-8] 这个进程占用IO 95%。

0x02 atop -dl 进一步确认IO 使用进程

PID       RDDSK         WRDSK         WCANCL          DSK             CMD
1437      0K              8004K         0K             99%             mysqld
535       0K              56K           0K              1%             jbd2/dm-0-8

确认是 Mysql 在占用IO。

0x03 解决问题

登录mysql ，查看sync_binlog变量的值：

[root@ubuntu ~]# mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2118462
Server version: 5.7.22 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 1     |
+---------------+-------+
1 row in set (0.00 sec)

mysql>

sync_binlog 值为1，表示每次提交事务后，将binlog_cache中的数据强制写入磁盘。这是最安全但是性能损耗最大的设置，系统Crash的时候最多丢失binlog_cache中未完成的一个事务；
sync_binlog 值为 0 时，表示当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。默认设置为 0，这时性能是最好的，但风险也是最大的，一旦系统Crash，cache中的所有binlog信息都会丢失；
sync_binlog 值为 n 时，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

所以sync_binlog=1，导致事务写入太频繁，从而出现 [jbd2/dm-0-8] 这个进程占用 IO 95%。

因此将sync_log设置为一个比较大的数，如 200。

mysql> set global sync_binlog=500;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 500   |
+---------------+-------+
1 row in set (0.00 sec)

mysql>

0x04 设置 innodb_flush_log_at_trx_commit 变量.

innodb_flush_log_at_trx_commit 是配置MySql日志何时写入硬盘的参数：

0：log buffer 将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行。该模式下在事务提交的时候，不会主动触发写入磁盘的操作。
1：每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去，该模式为系统默认。
2：每次事务提交时mysql都会把log buffer的数据写入log file，但是flush(刷到磁盘)操作并不会同时进行。该模式下，MySQL会每秒执行一次 flush(刷到磁盘)操作。

一般设置为2

mysql> show variables like '%innodb_flush_log_at_trx_commit%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1     |
+--------------------------------+-------+
1 row in set (0.01 sec)

mysql> set global innodb_flush_log_at_trx_commit=2;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%innodb_flush_log_at_trx_commit%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+
1 row in set (0.01 sec)