我在 amazon 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) 平均 CPU:%用户%nice%系统%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 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 平均 CPU:%用户%nice%系统%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
该产品运行良好,数据库没有记录任何慢速查询......
我应该如何调试这个问题?
编辑:
事实证明,所有卷均未表现出高延迟,并且系统的所有其他方面似乎都很健康。维基百科告诉我Linux 在平均负载中包含了不可中断状态的进程。ps 告诉我有两个挂起的 mount 命令处于这种状态:
ps auxww | grep " D " root 21557 0.0 0.0 9904 760 ? D Apr03 0:00 卸载 db /dev/xvdh root 26428 0.0 0.0 16456 912 ? D Apr03 0:00 挂载 /dev/xvdh /mnt/db
我害怕杀死它们(即使我尝试了,可能也不会起作用),所以我认为这个实例有问题,需要重新启动。谢谢你的帮助!
答案1
事实证明,所有卷均未表现出高延迟,并且系统的所有其他方面似乎都很健康。维基百科告诉我Linux 在平均负载中包含了不可中断状态的进程。ps 告诉我有两个挂起的 mount 命令处于这种状态:
ps auxww | grep " D " root 21557 0.0 0.0 9904 760 ? D Apr03 0:00 卸载 db /dev/xvdh root 26428 0.0 0.0 16456 912 ? D Apr03 0:00 挂载 /dev/xvdh /mnt/db
重新启动实例可以摆脱这些挂起的处理并且平均负载恢复正常。