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/s 左右。

运行 show full processlist在 mysql 中不显示任何查询(并且我禁用了所有将运行查询的东西)。在 MySQLWorkbench 的服务器状态选项卡中，我可以看到 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

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

包含数据的 block 不会立即写回磁盘。

UNIQUE 同上键。

对二级索引的更新进入“更改缓冲区”它们被折叠到索引 block 中，通常甚至更晚。

更新/删除会留下需要在事务完成后清理的“历史列表”。

这些事情由未显示在 PROCESSLIST 中的后台任务处理。 .它们可能在 mysqld 进程上可见，主要作为 I/O。 (CPU 可能是最小的。)
有没有 ROLLBACK ?交易“乐观”。所以一个 ROLLBACK必须做很多工作才能“撤消”乐观地已经 promise 的事情。
如果你突然杀死mysqld(或关闭电源)，那么 ROLLBACK重启后出现。
SSD 没有“寻道”时间。 HDD 必须以可变的量移动读/写磁头；这需要时间。如果您的 dd正在磁盘的一端工作， mysqld在另一端工作，“寻找”增加了明显的 I/O 时间。