磁盘io请求过高造成的io瓶颈怎么解决
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了磁盘io请求过高造成的io瓶颈怎么解决相关的知识，希望对你有一定的参考价值。
具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。
为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？
相信大部分做数据库运维的朋友，都遇到这种情况。 数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert操作， 需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？
dba此时心中有无限的疑惑，到底是什么原因呢? 磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？ 还是数据库内部出问题？昨天不是还好好的吗？
当数据库出现响应时间不稳定的时候，我们在操作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO. 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么操作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？
如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。
在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。
咱们先来提问题。 buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。
提问. 数据页不在buffer bool 里面该怎么办？
回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool, 图片中显示
buffer_read_page函数栈的顶层是pread64(),调用了操作系统的读函数。
buf_read_page的代码
如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的操作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer 中，无法直接使用该数据页，必须等待操作系统完成IO .
再接着上面的回答提问：
当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？ 代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。
试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool, 这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。 等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。
通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。
再继续扩展问题： 如果会话线程A 经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。
由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。
再回头来看上面的问题，mysql数据库出现性能下降时，可以看到操作系统有读IO。 原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写操作是不堵塞执行sql的会话线程的。所以，即使看到操作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在操作系统上基本看不到读的IO。 当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。
参考技术A 通过部署更多磁盘提升IO性能，或者部署价格昂贵的光纤存储，甚至是利用SSD硬盘。然而，当前企业购买大容量存储主要用于性能，而非容量。因此，需要提升存储的IO。虚拟化遇到的最大的瓶颈是IO瓶颈，进一步导致虚拟环境中存储成本猛增，虚拟化经应用性能不足等等。如何才能很好的解决这些问题?而不是简单地用磁盘叠加来解决。CPU的响应越来越快，然而，从存储的角度上来看，如果后端银盘没有很大的变化的话，哪怕升级到再高的存储也没有用。
FUSION—IO如何解决虚拟化的IO瓶颈?
FUSION—IO 成立于2006年，去年在纳斯达克上市。IBM、HP等都是我们的合作伙伴。
FUSION—IO 的架构其实很SAN是一样的，我们把SAN架构放到一个很小的PCIE卡上。我们跟独立的SAN存储是没有任何区别的。并且提供了5个9的可靠性。
FUSION—IO具有以下三大亮点：30多万IOPS，这需要上千块磁盘进行堆彻；低功耗；支持广泛的应用平台：包括主流的数据库、SAP等等。
比如上次双十一，淘宝的促销活动，一天成交200亿人民币，他们的核心数据库全部是架设在我们的卡上，所以我们再高负载的数据库或应用平台上具有很好的表现。
FUSION—IO可以支持所有的操作系统，包括VMware、SUSIE、Windows等。为虚拟机无缝提供IOPS。而且可以支持刀片服务器，刀片版本的卡可以直接插入到到片中。
FUSION—IO解决VDI的启动风暴。在一台server上可以支持6000个桌面。可以把卡插在Hypervisor的机器上，然后把OS image直接放到卡上就可以。此外，FUSION—IO还提供了IO sphere管理软件。本回答被提问者和网友采纳
mysql占用磁盘IO过高的解决办法
最近发现Mysql服务器磁盘IO一直很高
[root@push-5-221 ~]# iostat -k -d -x 1 10
Linux 3.10.0-957.el7.x86_64 (push-5-221) 2019年07月05日 _x86_64_ (8 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.08 0.00 14.89 0.09 177.79 23.88 0.34 23.05 5.42 23.05 11.01 16.40
dm-0 0.00 0.00 0.00 0.18 0.09 3.62 39.49 0.07 380.21 5.59 387.46 12.69 0.24
dm-1 0.00 0.00 0.00 0.00 0.00 0.01 8.98 0.00 91.25 12.04 92.94 6.55 0.00
dm-2 0.00 0.00 0.00 14.79 0.00 174.15 23.56 0.33 22.27 8.84 22.27 10.96 16.20
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 83.00 0.00 650.50 15.67 2.55 30.66 0.00 30.66 12.02 99.80
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 83.00 0.00 636.50 15.34 2.55 30.66 0.00 30.66 12.02 99.80
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 88.00 0.00 684.50 15.56 2.60 29.42 0.00 29.42 11.35 99.90
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 87.00 0.00 677.00 15.56 2.60 29.76 0.00 29.76 11.49 100.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 87.00 0.00 687.50 15.80 2.48 28.77 0.00 28.77 11.51 100.10
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 88.00 0.00 699.00 15.89 2.48 28.48 0.00 28.48 11.36 100.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 88.00 0.00 756.50 17.19 2.48 28.22 0.00 28.22 11.35 99.90
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 86.00 0.00 740.00 17.21 2.48 28.87 0.00 28.87 11.62 99.90%util已经接近100%了，IO性能严重瓶颈，这台服务器有两个Mysql实例，3306是主库，3307是另一台Mysql的从库，进入从库查看从库状态
mysql> show slave status\\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.28.5.223
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-223.000012
Read_Master_Log_Pos: 511363808
Relay_Log_File: push-5-221-relay-bin.000034
Relay_Log_Pos: 382425277
Relay_Master_Log_File: master-223.000012
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 382425062
Relay_Log_Space: 511364283
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 2345
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2233306
Master_UUID: 165a203c-8021-11e9-bc40-6c2b5992e592
Master_Info_File: /home/mysql-5.7.26/data/3307/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Reading event from the relay log
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
row in set (0.00 sec)
ERROR:
No query specified
mysql>Seconds_Behind_Master: 2345 发现从库同步延时很高，通过iotop查看
Total DISK READ : 0.00 B/s | Total DISK WRITE : 683.85 K/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 721.19 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
be/4 mysql 0.00 B/s 153.28 K/s 0.00 % 72.27 % mysqld --defaults-file=/etc/mysq~mysql/3307/mysql.sock --port=3307
be/4 mysql 0.00 B/s 27.51 K/s 0.00 % 8.51 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 11.79 K/s 0.00 % 7.50 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 11.79 K/s 0.00 % 7.47 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 0.00 B/s 0.00 % 7.41 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 35.37 K/s 0.00 % 7.14 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 27.51 K/s 0.00 % 6.77 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 15.72 K/s 0.00 % 6.31 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 15.72 K/s 0.00 % 5.32 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 7.86 K/s 0.00 % 5.05 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 7.86 K/s 0.00 % 5.00 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 47.16 K/s 0.00 % 4.21 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 0.00 B/s 0.00 % 3.63 % mysqld --defaults-file=/etc/mysq~mysql/3307/mysql.sock --port=3307
be/4 mysql 0.00 B/s 7.86 K/s 0.00 % 3.54 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 15.72 K/s 0.00 % 3.40 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 3.93 K/s 0.00 % 3.36 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 7.86 K/s 0.00 % 3.35 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 7.86 K/s 0.00 % 2.85 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 15.72 K/s 0.00 % 2.81 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 7.86 K/s 0.00 % 2.42 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 3.93 K/s 0.00 % 2.07 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 15.72 K/s 0.00 % 1.91 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 157.21 K/s 0.00 % 1.41 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 3.93 K/s 0.00 % 1.30 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 mysql 0.00 B/s 31.44 K/s 0.00 % 0.93 % mysqld --defaults-file=/etc/mysq~mysql/3307/mysql.sock --port=3307
be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.61 % [kworker/3:1]
be/4 mysql 0.00 B/s 27.51 K/s 0.00 % 0.00 % mysqld --defaults-file=/etc/mysq~mysql/3307/mysql.sock --port=3307
be/4 mysql 0.00 B/s 15.72 K/s 0.00 % 0.00 % mysqld --defaults-file=/etc/mysq~mysql/3306/mysql.sock --port=3306
be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd-udevd
be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd --system --deserialize 17发现3307和3306实例占用IO最高，进入3307实例，查看sync_binlog变量
mysql> show variables like '%sync_binlog%'
-> ;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
row in set (0.01 sec)
mysql>发现设置的是1，也就是说每次事务提交都会将binlog的缓存写入磁盘，严重影响磁盘效率，将变量设置为1000,
mysql> set global sync_binlog=1000;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1000 |
+---------------+-------+
row in set (0.00 sec)再查看innodb_flush_log_at_trx_commit参数
mysql> show variables like '%innodb_flush_log%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
rows in set (0.00 sec)设置为1，也就是说每次事务提交，都会将innodb日志缓存写入磁盘，对磁盘效率影响很大，将它设置为2，每次事务提交时mysql都会把log buffer的数据写入log file，但是flush(刷到磁盘)操作并不会同时进行。该模式下，MySQL会每秒执行一次 flush(刷到磁盘)操作
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%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 2 |
+--------------------------------+-------+
rows in set (0.00 sec)此时再查看从库同步状态
mysql> show slave status\\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.28.5.223
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-223.000012
Read_Master_Log_Pos: 539225447
Relay_Log_File: push-5-221-relay-bin.000034
Relay_Log_Pos: 490154357
Relay_Master_Log_File: master-223.000012
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 490154142
Relay_Log_Space: 539225922
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 1378
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2233306
Master_UUID: 165a203c-8021-11e9-bc40-6c2b5992e592
Master_Info_File: /home/mysql-5.7.26/data/3307/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: System lock
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
row in set (0.00 sec)
ERROR:
No query specified发现，同步延迟已经在很快缩小了，很快变为0，完全同步，这时通过iostat 查看io状态
[root@push-5-221 ~]# iostat -k -d -x 1 10/s 0.00 % 0.00 % [kworker/2:0H]
Linux 3.10.0-957.el7.x86_64 (push-5-221) 2019年07月05日 _x86_64_ (8 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.08 0.00 14.91 0.09 178.29 23.92 0.34 23.05 5.42 23.06 11.01 16.43
dm-0 0.00 0.00 0.00 0.18 0.09 3.62 39.48 0.07 380.15 5.59 387.40 12.69 0.24
dm-1 0.00 0.00 0.00 0.00 0.00 0.01 8.97 0.00 91.84 12.04 93.52 6.63 0.00
dm-2 0.00 0.00 0.00 14.81 0.00 174.66 23.59 0.33 22.28 8.84 22.28 10.96 16.23
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 114.00 0.00 2013.00 35.32 3.14 27.40 0.00 27.40 8.75 99.80
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 113.00 0.00 2007.50 35.53 3.14 27.65 0.00 27.65 8.83 99.80
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 108.91 0.00 3026.24 55.57 3.10 27.85 0.00 27.85 9.05 98.51
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 111.88 0.00 3121.29 55.80 3.10 27.11 0.00 27.11 8.81 98.51
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 98.00 0.00 2648.00 54.04 2.81 29.63 0.00 29.63 9.71 95.20
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 95.00 0.00 2551.50 53.72 2.81 30.59 0.00 30.59 10.02 95.20
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 103.00 0.00 2037.00 39.55 2.97 28.67 0.00 28.67 9.12 93.90
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 104.00 0.00 2051.00 39.44 2.97 28.39 0.00 28.39 9.03 93.90发现%util依旧差不多100%，磁盘IO性能还是很低，我们再把3306实例的变量设置改一下
[root@push-5-221 ~]# mysql -uroot -p -S /var/lib/mysql/3306/mysql.sock
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \\g.
Your MySQL connection id is 1476252
Server version: 5.7.26-log MySQL Community Server (GPL)
Copyright (c) 2000, 2019, 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 |
+---------------+-------+
row in set (0.01 sec)
mysql> set global sync_binlog=1000;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like '%innodb_flush_log%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
rows in set (0.00 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%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 2 |
+--------------------------------+-------+
rows in set (0.00 sec)
mysql>此时，再通过iostat查看IO
[root@push-5-221 ~]# iostat -k -d -x 1 10
Linux 3.10.0-957.el7.x86_64 (push-5-221) 2019年07月05日 _x86_64_ (8 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.08 0.00 14.92 0.09 178.36 23.92 0.34 23.06 5.42 23.06 11.01 16.43
dm-0 0.00 0.00 0.00 0.18 0.09 3.62 39.48 0.07 380.15 5.59 387.39 12.69 0.24
dm-1 0.00 0.00 0.00 0.00 0.00 0.01 8.97 0.00 91.84 12.04 93.52 6.63 0.00
dm-2 0.00 0.00 0.00 14.81 0.00 174.72 23.59 0.33 22.28 8.84 22.28 10.96 16.23
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 21.00 0.00 604.00 57.52 0.38 18.10 0.00 18.10 13.76 28.90
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 21.00 0.00 604.00 57.52 0.38 18.10 0.00 18.10 13.76 28.90
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 34.00 0.00 2220.50 130.62 1.29 37.88 0.00 37.88 12.88 43.80
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 34.00 0.00 2220.50 130.62 1.29 37.88 0.00 37.88 12.88 43.80
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 42.00 0.00 2056.00 97.90 1.29 30.67 0.00 30.67 9.40 39.50
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 42.00 0.00 2056.00 97.90 1.29 30.67 0.00 30.67 9.40 39.50
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 21.00 0.00 550.00 52.38 0.34 16.19 0.00 16.19 13.76 28.90
dm-0 0.00 0.00 0.00 2.00 0.00 1.50 1.50 0.05 24.00 0.00 24.00 24.00 4.80
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 19.00 0.00 548.50 57.74 0.29 15.37 0.00 15.37 12.74 24.20
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 18.00 0.00 524.00 58.22 0.34 18.61 0.00 18.61 13.33 24.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 18.00 0.00 524.00 58.22 0.34 18.61 0.00 18.61 13.33 24.00%util已经顺利降到40%左右了。
本文乃抄袭所得，仅为学习而已， 抄袭地址为：https://www.cnblogs.com/tv151579/p/8288905.html
如有侵权，请联系本人。
以上是关于磁盘io请求过高造成的io瓶颈怎么解决的主要内容，如果未能解决你的问题，请参考以下文章