记一次mysql磁盘io高的问题排查

现象是，系统里的java连接mysql超时了，

于是去mysql的机器，查看/var/log/messages日志，查对应的时间点的情况

发现mysql被阻塞了blocked for more than 120 seconds，mysql的io非常之高，用top查看系统的负载也到达了50的样子

用mpstat查看cpu情况

好明显，都在等io

用iostat查看io情况，%util的值，一直在80%，99%之间变化

以为磁盘有问题，用dd测下速看看

从上面的结果看，也还好，没问题

以为可能磁盘有坏道，用下面命令也扫了一遍，没问题

结果也没有坏的块，这个过程，很耗时。

用show processlist命令查看mysql正在忙着什么，一看，也没什么任务在执行的

想看看mysql，研究写哪个文件时，最耗时的

从上面结果来看，xxl_job是最耗时的。知道点眉目了，因为公司的定时任务是用的xxljob，定时任务里，有每几秒执行的任务，我猜它的日志记录一定很大，于是查看一下

我的天，这个表的记录有千万！！！这些记录，没做定时任务来清理，由于都是一些没用的记录，所以这个表的数据我全清了

清了之后，再用iostat查看

%util一下子就降下来了，用iotop查看mysql进程的io也下降了

cpu的iowait也下降了

定义一个事件，让mysql定时清理30天前的日志记录

记录一下，希望对有需要的朋友也起一点提示

1、之前偶尔也会出现个别readonly的情况，没有深入排查，只是推测和chunkserver磁盘坏道有关，当vm读写正好在chunkserver坏道的块上时，可能出现报错，导致异常。

2、此次出现大批量readonly，且监控和日志显示均是在凌晨出现，故排除磁盘坏道问题。

3、如果虚拟机上承载docker 、mysql 等可能造成大并发的业务，也可能造成此类问题。但是虚拟机镜像在mfs上是连续的空间，正常的mysql读写并不会有问题。有出现在vm上进行批量docker容器删除时，出现异常的情况。

4、推测有vm用户提交了大量并发的读写任务，而我们并未对虚拟机读写进行限制，也有可能造成此类问题。前期有vm出现load 90+ 报警,紧接着就有chunkserver出现load 100+的报警，和此问题非常类似。

排查定位：

1、检查宿主机负载、网络等，未发现异常情况。

2、检查mfschunkserver ，发现有部分磁盘出现raid errro。

3、检查mfschunkserver ，发现有一台chunkserver出现load +100，iowait达到90%以上的情况，带宽未见异常，写入的数据量也很低，现象大概持续3分钟左右。

4、检查vm在凌晨的监控情况，发现批量机器出现iowait达到100%，流量、load均未见明显异常。有部分vm上有大量的sendmail进程。

5、检查虚拟机上凌晨的crontab、进程等，没有发现异常。

6、检查mfs上的读写情况，未见在凌晨有大量的 chunk create 和replica，但是 max operations in queue 值特别高。

7、检查虚拟机备份程序，发现正好是在凌晨0:10进行备份，执行了snapshot *** 作，而且每台vm备份间隔仅1s，初步确认此备份为导致异常的主要原因。

由于snapshot *** 作并未带来大量的读写，之前并未关注到。在深入剖析了snapshot的原理，发现是执行了类似linux 系统的硬链接 *** 作，此时批量的snapshot虚拟机，200台vm大概20TB，按照mfs的每个chunk块 64MB的划分，换算下来执行一次 *** 作，会产生 2010241024/64 = 327680 创建链接的 *** 作，每台vm备份也会产生1600次 *** 作，如果在1s内没有完成，那么cpu队列就会越来越大，从而产生了load和iowait都非常高的现象。由于镜像备份并不是十分紧急的任务，故将间隔时间修改到60s执行一台。

可能造成虚拟机readonly故障的原因：

1、虚拟机备份进程的批量 *** 作产生大量的并发，导致chunkserver 的cpu队列拥塞，产生vm读写出现iowait过高超时的情况，从而造成了磁盘remount为readonly的情况。故有此类批量 *** 作的动作，一定要考虑并发负载的问题。 因为chunkserver是存储型服务器，cpu配置都比较低。

2、个别vm用户大量的提交任务导致后端异常。针对此现象，使用cgroug 进行io限制。可避免此类问题发生。

3、mfschunkser 规格建议配置一致，避免读写负载出现不均衡的情况。

此次定位问题耗时一周：

1、监控不到位，由于zabbix 进行大批量机器对比时，效率很低，临时部署了openfalcon和grafana，耗时较长。

2、没有关注到备份任务，之前一致以为是vm用户的问题，但是通过监控定位并不是用户的问题。

3、对mfs的snapshot未深入理解。

    具体问题具体分析，举例来说明为什么磁盘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，数据库的性能会非常差。

---