即使没有运行查询，MySQL 的磁盘活动也很繁重

Question

尝试解决由 MySQL 引起的神秘磁盘 io 瓶颈问题。

我正在使用以下命令来测试磁盘读/写速度：

#write
dd if=/dev/zero of=/tmp/writetest bs=1M count=1024 conv=fdatasync,notrunc

#read
echo 3 > /proc/sys/vm/drop_caches; dd if=/tmp/writetest of=/dev/null bs=1M count=1024

我重新启动了机器，禁用了 cron，所以我通常的进程都没有运行查询，杀死了通常运行的 Web 服务器，并杀死了 mysqld。

当我在没有运行 mysqld 的情况下运行读取测试时，我得到1073741824 bytes (1.1 GB) copied, 2.19439 s, 489 MB/s。始终保持在 450-500 MB/s 左右。

当我开始备份mysql服务，然后再次运行读取测试，我得到1073741824 bytes (1.1 GB) copied, 135.657 s, 7.9 MB/s。始终保持在 5MB/秒左右。

在 mysql 中运行 show full processlist 不会显示任何查询（而且我禁用了所有将运行查询的东西）。在 MySQLWorkbench 的 Server Status 选项卡中，我可以看到 InnoDB 读取在每秒 30-200 次读取和每秒 3-15 次写入之间波动，即使没有运行查询。

如果我运行iotop -oPa，我可以看到当没有查询运行时，mysqld 每秒读取 1MB 磁盘。考虑到没有查询正在运行，这似乎很多，但同时这似乎不足以导致我的 dd 命令花费这么长时间......执行磁盘 io 的唯一另一件事是 jbd2/sda3-8。

不确定它是否相关，但如果我尝试使用service mysql stop 终止 mysql 服务器，它会显示“尝试停止 MySQL 超时”，并且 mysqld 进程继续运行，但我无法再连接到数据库。我必须使用kill -9 来杀死mysqld 进程并重新启动服务器。

所有这一切似乎都出乎意料。这台服务器几个月来一直在进行繁重的日志解析、大量插入和选择，直到上周末我们开始看到这个磁盘 io 瓶颈。

我怎样才能找出为什么 MySQL 在它基本上空闲时会进行如此多的磁盘读取？

Answer 1

您是否更新/删除/插入大量行？如果是这样，请考虑写入磁盘时的这些“延迟”：

• 包含数据的块不会立即写回磁盘。
• UNIQUE 键也是如此。
• 对二级索引的更新进入“更改缓冲区”。它们被折叠到索引块中，通常甚至更晚。
• 更新/删除会留下需要在事务完成后清理的“历史列表”。

这些事情由PROCESSLIST 中未显示的后台任务处理。它们可能在 mysqld 进程上可见，主要作为 I/O。 （CPU 可能是最小的。）

有ROLLBACK吗？交易“乐观”。所以ROLLBACK 必须做很多工作来“撤销”乐观地已经承诺的事情。

如果你突然杀掉mysqld（或者关闭电源），那么重启后会出现ROLLBACK。

SSD 没有“寻道”时间。 HDD 必须以可变的量移动读/写磁头；这需要时间。如果您的dd 在磁盘的一端工作，而mysqld 在另一端工作，则“查找”会增加明显的 I/O 时间。

Answer 2

事实证明，与许多性能问题一样，这是一个多方面的问题。

基本上问题出在夜间系统和数据库备份写入到一个单独的 HDD RAID 阵列运行到第二天，然后主机发送 FLUSH TABLES 并导致 mysql 作业和复制工作等待。此外，每天几次在系统周围复制数 GB 文本文件的不必要的副进程。大量的上下文切换，因为系统试图复制数据以进行备份，同时还执行 mysql 工作（复制和其他工作）。

我最终减少了我们要复制的表的数量（有些是不必要的），在不需要时减少了系统周围文本文件的复制，增加了分配给 mysql 服务器的内存和 io，简化了 mysql 备份和系统备份，并限制运行 mysql 进程的 cron 作业，以使 mysql 备份有更多时间完成。尽管如此，每天早上 7 点之前备份几乎没有完成，所以我最终确定我们只需要在周末而不是每晚运行 mysql 备份，这很好，因为这都是相当静态的数据。