0

尝试解决由 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 左右。

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

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

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

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

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

4

2 回答 2

1

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

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

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

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

如果您突然杀死mysqld（或关闭电源），则ROLLBACK在重新启动后会发生这种情况。

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

于 2020-05-30T03:23:18.197 回答
0

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

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

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

于 2020-06-10T19:41:35.770 回答