我正在使用 Ubuntu 服务器 12.04，很难找到负载的原因，我发现过去一周服务器的响应时间发生了变化
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 操作
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
答案1
调整你的mysql服务以避免接触磁盘，并留意你的postfix队列，你可能将大量的电子邮件放入I/O敏感队列（即延迟的、具有随机读取行为的小项目）。
您的电子邮件系统已被用作垃圾邮件发送者的中继。
看一眼postfix 文档并限制对您的 MTA 的中继访问。
答案2
使用 iostat 和 iotop 收集更多信息后进行编辑
您的磁盘已满 100%，因为它的可用 IOPS 已耗尽：根据 iostat，您拥有恒定的 50+ IOPS（85 w/s - 35 合并 w/s）。EC2 实例（尤其是廉价实例）对持续 IOPS 有严格的限制（在 30-50 IOPS 范围内）。
根据新的 iotop 输出，mysql 和 bounce 都消耗了大量 IOPS。但是，iotop 的输出似乎不完整，或者至少排序很差。您可以重新运行“iotop -a”，一次按 IOPS 排序，另一次按磁盘写入排序吗？
原始答案
我的赌注：“反弹”过程正在发出许多同步写入，这些写入会阻塞亚马逊提供的虚拟磁盘设备（顺便问一下，您使用的是什么配置文件？EC2 磁盘对于持续 I/O 与突发 I/O 有非常严格的规则）。
无论如何，确定消耗 I/O 带宽的因素有时可能有些困难。虽然 iotop 是一款非常好的工具，但有时它不会提供所需的信息。我们需要更深入地研究。因此，请遵循以下建议：
- 首先，我们需要识别正在处理的 I/O 类型和受影响的块设备。
请运行以下命令：iostat -x -k 5 2。请报告两个结果集。 - 然后，我们需要识别等待 I/O 的进程。
何时可以使用“top”：启动它，按 shift+f (F)，然后按 w，然后按 Enter，然后按 shift+r (R)。第一个进程将是处于 D 或 D+ 状态的进程（即：等待磁盘/网络）。请报告列表。 - 使用 iotop 显示进程的累积 I/O 值。
运行iotop -a约一分钟并将输出粘贴到这里。
答案3
虽然有点晚了，但我在类似的机器上也遇到了同样的问题，发现问题出在一堆损坏的 MySQL 表上。由于其中一些表包含大量数据，因此会产生大量 I/O 等待时间。
查看/var/log/mysql/error.log或使用它mysqlcheck来查找和修复损坏的数据。
答案4
磁盘可能处于非 DMA 模式。请检查驱动器的 DMA 状态。（hdparm 命令）
如果不是这样，其他东西可能会产生大量中断。有人还记得那些来自古老 DOS 时代的中断吗？