在EC2实例上的Ubuntu 12.04中由于I / O等待而导致高负载

我正在使用Ubuntu服务器12.04，无法找到负载原因，从上周开始我已经看到服务器响应时间的变化

阅读Linux故障排除，第一部分：高负载后

看来CPU和RAM没有问题，并且 使用我得到以下输出的命令，此负载可能与I / O绑定负载有关top

在这里97.6%wa，RAM是空闲的，不使用任何交换。

以下是iostat播种有的命令的输出89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

我还使用了iotop修复间隔显示99％I / O后，磁盘将I观察者写为1266 KB/s

和

是不好吗？随着响应时间的缩短。是什么原因造成的？

其他人要求的编辑

iftop O / P

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

输出 iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@shodanshok点2

iotop -a

调整您的mysql服务，以避免接触磁盘并在后缀队列中当心，您可能会有很多电子邮件进入I / O敏感队列（即，延迟，带有随机读取行为的小消息）。

您的电子邮件系统已被用作垃圾邮件发送者的中继。

查看postfix文档，并限制对MTA的中继访问。

在使用iostat和iotop收集其他信息之后进行编辑，因为
磁盘在可用IOPS耗尽时已被100％加载：根据iostat，您具有恒定的50+ IOPS（85 w / s-35合并w / s）。EC2实例（尤其是廉价实例）对持续IOPS（在30-50 IOPS范围内）具有强大的限制。

根据新的iotop输出，mysql和bounce都在消耗大量的IOPS。但是，iotop的输出似乎不完整，或者至少排序不正确。您是否可以重新运行“ iotop -a”，一次按IOPS排序，另一次按磁盘写入排序？

原始答案
我敢打赌：“反弹”过程正在发出许多同步写入，这些写入阻塞了Amazon提供的虚拟磁盘设备（顺便说一句，您使用的是什么配置文件？EC2磁盘对于持续I / O与突发I / O具有严格的规则）。

无论如何，有时很难确定正在燃烧的I / O带宽。尽管iotop是一个非常好的工具，但有时它无法提供所需的信息。我们需要更深入。因此，请遵循以下建议：

1. 首先，我们需要确定正在处理的I / O的类型以及受影响的块设备。
   请运行以下命令：iostat -x -k 5 2。请报告两个结果集。
2. 然后，我们需要确定等待I / O的进程。
   何时可以使用“顶部”：启动它，按shift + f（F），然后按w，然后输入，然后按shift + r（R）。第一个进程将是处于D或D +状态的进程（即：等待磁盘/网络）。请向后报告该列表。
3. 使用iotop显示进程的累积I / O值。
   运行iotop -a大约一分钟，然后将输出粘贴到此处。

有点晚了，但是我在类似的机器上遇到了同样的问题，发现问题是一堆损坏的MySQL表。由于其中一些表包含大量数据，因此产生了大量I / O等待时间。

查看/var/log/mysql/error.log或用于mysqlcheck查找和修复损坏的数据。

如上所述，您的EC2实例很有可能带有IO上限，或者很有可能是由Amazon EBS Standard卷支持的，该卷根本无法提供太多IO。看一下该页面 -它描述了Amazon提供的不同卷类型。

即使您的卷确实很慢，您仍然应该可以对其进行快速写入，但是如果您的负载是自然随机的（似乎是SQL的东西），则可能需要升级IOPS容量，因为这通常使SQL性能达到上限。

所以-从您的数量来看，使用标准存储可能会用完IOPS。购买更快的存储并不昂贵。看看这个。

磁盘可能处于非DMA模式。请检查驱动器的DMA状态。（hdparm命令）

如果不是那样，其他的东西可能会产生很多中断。有人还记得DOS时代的那些人吗？