☰

Percona 的磁盘 IO 峰值达到 99%

tag-icon • tag-icon linux mysql hard-drive io percona
Percona 的磁盘 IO 峰值达到 99%

因此，我们的服务器似乎会出现随机的磁盘 I/O 峰值，在随机时间毫无原因地上升到 99.x%，保持一段时间后又回落。这以前不是问题，但最近磁盘 I/O 长时间保持在 99%，有时长达 16 小时。

该服务器是专用服务器，具有 4 个 CPU 核心和 4 GB RAM。它运行 Ubuntu Server 14.04.2，运行 percona-server 5.6，没有其他主要软件。我们正在监控它的停机时间，并且我们有一个屏幕永久显示我们处理的服务器的 CPU/RAM/磁盘 I/O。该服务器也定期进行修补和维护。

该服务器是副本链中的第三个服务器，用作故障转移机器。MySQL 数据流如下。

主服务器 --> 主/从服务器 --> 问题服务器

所有 3 台机器的规格相同，并由同一家公司托管。问题服务器与第一和第二台位于不同的数据中心。

“iotop”工具显示磁盘 I/O 是由“jbd2/sda7-8”进程引起的。据我们所知，它处理文件系统日志，并将内容刷新到磁盘。我们的“sda7”分区是“/var”，我们的 sda8 分区是 /home。不应该有任何东西定期读取/写入 /home。停止 mysql 服务会导致磁盘 I/O 立即回落到正常水平，因此我们相当肯定是 percona 导致了这个问题，这与它是 /var 分区相匹配，因为这是我们的 MySQL 数据目录所在的位置（/var/lib/mysql）。

我们使用 NewRelic 来监控所有服务器，当磁盘 I/O 达到峰值时，我们无法发现任何可能导致该情况的原因。平均负载约为 2。CPU 使用率徘徊在约 25% 左右，NewRelic 表示这是由“IO 等待”而不是特定进程引起的。

我们的 mysql 配置文件是通过 Percona 配置向导和客户应用程序所需的一些设置组合生成的，但没有什么特别的。

MySQL 配置 -http://pastebin.com/5iev4eNa

我们尝试了以下方法来解决这个问题：

  • 运行 mysqltuner.pl 以查看是否有任何明显错误。结果看起来与其他 2 个数据库服务器上的同一工具的结果非常相似，并且在使用之间没有太大变化。

  • 使用了 vmstat、iotop、iostat、pt-diskstats、fatrace、lsof、pt-stalk 以及可能还有其他一些工具，但没有发现任何明显的效果。

  • 调整了“innodb_flush_log_at_trx_commit”变量。尝试将其设置为 0、1 和 2，但似乎没有任何效果。这应该会改变 MySQL 将事务刷新到日志文件的频率。

  • 当磁盘 I/O 很高时，mysql 的“显示完整进程列表”非常无趣，它仅显示从主服务器读取的从属服务器。

一些工具的输出显然很长，所以我会提供 pastebin 链接，而且我无法复制粘贴 iotop 的输出，因此我提供了一个屏幕截图。

iotop

IOTop

pt-磁盘统计：http://pastebin.com/ZYdSkCsL

当磁盘 I/O 较高时，“vmstat 2”向我们显示正在写入的内容主要是由于“bo”（缓冲区输出），这与磁盘日志记录（将缓冲区/RAM 刷新到磁盘）相关

http://pastebin.com/E3LWzwjj

“lsof -p mysql-pid”（列出进程的打开文件）向我们显示，正在写入的文件主要是 /var/lib/mysql 目录中的 .MYI 和 .MYD 文件，以及 master.info 和 Relay-bin 和 Relay-log 文件。即使没有指定 mysql 进程（因此整个服务器上的任何文件都在写入），输出也非常相似（主要是 MySQL 文件，没有太多其他内容）这向我证实了它肯定是由 Percona 引起的。

当磁盘 I/O 较高时，“seconds_behind_master” 会增加。我目前还不确定它们是如何发生的。“seconds_behind_master” 也会暂时从正常值跳转到任意大的值，然后几乎立即恢复正常，有些人认为这可能是由网络问题引起的。

‘显示从属状态’-http://pastebin.com/Wj0tFina

RAID 控制器 (3ware 8006) 不具备任何缓存能力；有人还指出缓存性能不佳可能导致此问题。该控制器的固件、版本、修订版等与同一客户的其他服务器（尽管是 Web 服务器）上的卡相同，因此我相当确定这不是问题所在。我还对阵列进行了验证，结果很好。我们还有 RAID 检查脚本，它会提醒我们任何更改。

与第二台数据库服务器相比，网络速度非常糟糕，所以我认为这可能是一个网络问题。这也与磁盘 I/O 高峰之前的带宽峰值有关。但是，即使网络确实“激增”，流量也不会激增到很高的水平，只是与平均值相比相对较高。

网络/磁盘 IO

网络速度（使用 iPerf 生成到 AWS 实例）

问题服务器 - 0.0-11.3 秒 2.25 MBytes 1.67 Mbits/sec 第二台服务器 - 0.0-10.0 秒 438 MBytes 366 Mbits/sec

除了速度慢之外，网络似乎还不错。没有丢包，但服务器之间的跳转速度有些慢港铁

也很乐意提供任何相关命令的输出，但由于我是新用户，我只能在此帖子中添加 2 个链接 :(

编辑我们就此问题联系了我们的托管服务提供商，他们很好心地将硬盘换成了相同大小的 SSD。我们在这些 SSD 上重建了 RAID，但不幸的是问题仍然存在。

答案1

您使用哪个版本的 MySQL 服务器？5.5 之后，您可以使用 performance_schema 从数据库获取实时统计信息。我会开始查询

 table_io_waits_summary_by_table
 table_io_waits_summary_by_table
 table_lock_waits_summary_by_table

看看到底发生了什么。

另一个解决方案是，如果您检查缓冲池的使用情况，是否有可能需要将冷页面移至内存？

答案2

攻击它的最好方法是看http://www.brendangregg.com/linuxperf.html并听从布伦丹的建议。

具体来说，您需要他的 iosnoop 工具来告诉您谁最常访问存储。但如果您通读它以了解他的思维过程和方法，您将会对自己有很大帮助，因为从长远来看，这将使您受益匪浅。

相关内容