我在亚马逊ec2 ubuntu 11.04大型实例上，为数据库安装了150GB卷（ext4）。
CPU使用率非常低，但现在一天的平均负载一直在2.0。 我曾经有一个40GB的数据库分区，并没有这个问题。
iostat告诉我，我们花了很多时间等待io：
：〜$ iostat 1 2
Linux 2.6.38-11-virtual（flashgroup）04/05/2012 _x86_64_（2 CPU）
avg-cpu：％user％nice％system％iowait％steal％idle
7.16 0.09 2.62 1.11 2.09 86.92
设备：tps kB_read / s kB_wrtn / s kB_read kB_wrtn
xvdap1 3.45 0.88 18.59 9137065 192742888
xvdb 4.47 2.84 24.17 29479675 250638760
xvdh 10.62 19.95 88.05 206811124 912892410
xvdf 0.18 0.00 1.93 1378 19971464
xvdg 0.00 0.00 0.00 656 0
avg-cpu：％user％nice％system％iowait％steal％idle
5.22 0.00 1.92 42.58 3.02 47.25
设备：tps kB_read / s kB_wrtn / s kB_read kB_wrtn
xvdap1 0.00 0.00 0.00 0 0
xvdb 43.00 0.00 172.00 0 172
xvdh 0.00 0.00 0.00 0 0
xvdf 49.00 0.00 288.00 0 288
xvdg 0.00 0.00 0.00 0 0
该产品执行得很好，数据库不logging任何慢速查询…
我应该如何去debugging呢？
编辑：
事实certificate，没有一个卷performance出高延迟，系统的所有其他方面似乎是健康的。 维基百科告诉我 ，linux在负载平均状态下包含处于不可中断状态的进程。 ps告诉我有两个挂载命令处于这种状态：
ps auxww | grep“D” 根21557 0.0 0.0 9904 760？ D Apr03 0:00 umount db / dev / xvdh 根26428 0.0 0.0 16456 912？ D Apr03 0:00 mount / dev / xvdh / mnt / db
我害怕杀死这些（如果我尝试了可能不会工作），所以我认为这个实例是生病，需要重新启动。 谢谢你的帮助！
事实certificate，没有一个卷performance出高延迟，系统的所有其他方面似乎是健康的。 维基百科告诉我 ，linux在负载平均状态下包含处于不可中断状态的进程。 ps告诉我有两个挂载命令处于这种状态：
ps auxww | grep“D” 根21557 0.0 0.0 9904 760？ D Apr03 0:00 umount db / dev / xvdh 根26428 0.0 0.0 16456 912？ D Apr03 0:00 mount / dev / xvdh / mnt / db
重新启动实例摆脱了这些挂起处理，平均负载恢复正常。