Percona的99％磁盘IO峰值

所以我们有一个服务器，在磁盘I / O上看似随机高峰，随机时间上升到99.x％，而且没有明显的原因，一段时间后保持高位，然后又回落。 这并不是一个问题，但最近磁盘I / O一直保持在99％的长时间，在某些情况下长达16小时。

服务器是专用服务器，具有4个CPU核心和4 GB的RAM。 它正在运行Ubuntu服务器14.04.2，运行percona-server 5.6，没有别的主要。 正在监视停机时间，我们有一个屏幕永久显示我们处理的服务器的CPU / RAM /磁盘I / O。 服务器也经常修补和维护。

这个服务器是复制链中的第三个，并作为故障转移机器。 MySQL数据stream如下。

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

• 为什么ZFS比ext4和btrfs慢得多？
• NAS上的文件夹可以作为VMWare中的物理驱动器使用吗？
• 西数WD15EARS磁盘速度不可思议
• 顶点2 SSD一次冻结60秒
• 针对不同硬盘制造商的SMART“开机时间”属性

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

'iotop'工具告诉我们磁盘I / O是由'jbd2 / sda7-8'进程造成的。 据我们所知，这将处理文件系统日志，并将东西刷新到磁盘。 我们的'sda7'分区是'/ var'，我们的sda8分区是/ home。 没有什么应该定期读/写/回家。 停止mysql服务会导致磁盘I / O立即下降到正常水平，所以我们相当肯定这是导致问题的percona，并且这将与它作为/ var分区相匹配，因为这是我们的MySQL数据目录驻留（/ var / lib / mysql）。

我们使用NewRelic监视所有的服务器，当磁盘I / O出现峰值时，我们看不到任何可能导致它的事情。 平均负荷为-2。 CPU使用率徘徊在〜25％，NewRelic认为是由“IO等待”造成的，而不是一个特定的进程。

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

MySQLconfiguration – http://pastebin.com/5iev4eNa

我们尝试了以下事情来尝试解决问题：

• 冉mysqltuner.pl看看是否有什么明显的错误。 结果看起来与其他2台数据库服务器上的相同工具的结果非常相似，并且在使用情况之间变化不大。

• 使用vmstat，iotop，iostat，pt-diskstats，fatrace，lsof，pt-stalk，可能还有更多，但没有明显的跳出来。

• 调整了'innodb_flush_log_at_trx_commit'variables。 曾尝试将其设置为0,1和2，但没有任何效果。 这应该已经改变了MySQL刷新事务到日志文件的频率。

• 当磁盘I / O很高时，mysql'show full processlist'是非常有趣的，它只是显示从主机读取的从机。

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

iotop

pt-diskstats： http ：//pastebin.com/ZYdSkCsL

当磁盘I / O为高时，“vmstat 2”显示正在写入的内容主要是因为“bo”（缓冲区输出），这与磁盘日志logging（缓冲区/内存到磁盘）

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”也暂时从正常值跳到任意大的值，然后几乎立即恢复正常，有人提出这可能是networking问题造成的。

'显示奴隶状态' – http://pastebin.com/Wj0tFina

RAID控制器（3ware 8006）没有任何cachingfunction。 有人还build议caching性能不佳可能会导致问题。 该控制器具有相同的固件，版本，修订等在同一客户（尽pipenetworking服务器）在其他服务器上的卡，所以我相当肯定，这是没有错。 我也跑了arrays的validation，回来很好。 我们也有RAID检查脚本，它会提醒我们任何改变。

networking速度比第二台数据库服务器的速度糟糕，所以我想这可能是networking问题。 这也与磁盘I / O变高之前的带宽尖峰相关。 然而，即使networking“飙升”，它也不会飙升到很高的stream量，只是比较高的平均水平。

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

问题服务器 – 0.0-11.3秒2.25兆字节1.67兆比特/秒秒服务器 – 0.0-10.0秒438兆字节366兆比特/秒

除了缓慢，networking似乎没有问题。 没有数据包丢失，但服务器之间有一些缓慢的跳跃

也很高兴也提供任何相关命令的输出，但我只能添加2个链接到这个职位，因为我是一个新的用户:(

编辑我们与我们的托pipe服务提供商就此问题取得了联系，他们很友善地交换相同大小的SSD的硬盘。 我们将RAID重build到这些SSD上，但不幸的是问题仍然存在。

table_io_waits_summary_by_table table_io_waits_summary_by_table table_lock_waits_summary_by_table