linux – Percona 99％的磁盘IO峰值

概述因此,我们有一个服务器,在磁盘I / O中看似随机的峰值,随机时间高达99.x％,没有明显的原因,保持高位一段时间,然后再回落.这不是一个问题,但最近磁盘I / O长时间保持在99％,在某些情况下长达16小时. 该服务器是一个专用服务器,具有4个CPU内核和4 GB RAM.它正在运行Ubuntu Server 14.04.2,运行percona-server 5.6,没有其他主要功能.它正在监控 因此,我们有一个服务器,在磁盘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.服务器也经常被修补和维护.

此服务器是副本链中的第3个,并且作为故障转移计算机存在. 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“show full processList”非常有趣,它只显示从主设备读取的从设备.

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

iotop

pt-diskstats：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变高之前的带宽峰值有关.然而,即使网络“尖峰”,它也不会达到大量流量,与平均值相比只是相对较高.

网络速度(使用iPerf生成到AWS实例)

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

除了缓慢之外,网络看起来还不错.没有丢包,但服务器之间有一些慢跳

很乐意也提供任何相关命令的输出,但我只能添加2个链接到这篇文章,因为我是一个新用户:(

编辑我们与我们的托管服务提供商就此问题取得了联系,他们非常友好地将硬盘交换为相同大小的SSD.我们将RAID重建到这些SSD上,但不幸的是问题仍然存在.

解决方法 您使用的是哪个版本的MysqL服务器？
在5.5之后,您可以使用performance_schema从数据库中获取实时统计信息.
我开始查询了

table_io_waits_summary_by_table table_io_waits_summary_by_table table_lock_waits_summary_by_table

看看究竟发生了什么.

另一种解决方案是,如果您检查缓冲池使用情况,那么有可能需要移动到内存的冷页面？

总结

以上是内存溢出为你收集整理的linux – Percona 99％的磁盘IO峰值全部内容，希望文章能够帮你解决linux – Percona 99％的磁盘IO峰值所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。