我们有一个 Ubuntu 10.4 VPS 为 Rails 网站提供服务，该网站经常显示相当高的负载，但 CPU 或内存数量并不高。阅读了很多其他问题Server Fault 上的提示告诉我，这是一个I/O 问题（即有些进程卡在 I/O 等待状态，因此导致负载增加）。我正在尝试追踪这些进程，但运气不佳。如果能帮助我 (a) 找到罪魁祸首，和/或 (b) 确认我问的是正确的问题，我将不胜感激。
以下是快照top：
顶部 - 18:28:49 启动 5 天，3:07，2 个用户，平均负载：1.79、1.83、1.73 任务：共 82 个，1 个正在运行，81 个正在休眠，0 个已停止，0 个僵尸 CPU：0.0％us、0.3％sy、0.0％ni、99.6％id、0.0％wa、0.0％hi、0.0％si、0.1％st 内存：总计 1794980k，已用 1780384k，可用 14596k，缓冲区 13356k 交换：总计 524284k，已使用 3116k，可用 521168k，缓存 1012272k
注意低交换，CPU 大部分处于空闲状态；这就是为什么我认为我们受到 I/O 限制而不是内存或 CPU 限制。
这是iostat（我混淆了服务器名称）：
$ iostat -x 1 3
Linux 2.6.35.2-xenU (our.server.com) 03/25/11 _x86_64_ (2 CPU)
平均 CPU：％用户％nice％系统％iowait％steal％idle
1.75 0.19 0.50 0.31 0.01 97.24
设备：rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvdap1 0.01 11.52 2.19 3.18 145.12 117.55 48.97 0.08 15.60 1.67 0.90
xvdap9 0.01 0.01 0.00 0.00 0.10 0.14 62.62 0.00 13.20 6.09 0.00
平均 CPU：％用户％nice％系统％iowait％steal％idle
0.00 0.00 0.00 0.00 0.00 100.00
设备：rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvdap1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdap9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
平均 CPU：％用户％nice％系统％iowait％steal％idle
0.00 0.00 0.00 0.00 0.00 100.00
设备：rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvdap1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdap9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
iotop无法在此盒子上运行：
$ iotop 无法运行 iotop，因为某些要求未得到满足： - Linux >= 2.6.20 具有 I/O 统计支持 (CONFIG_TASKSTATS、CONFIG_TASK_DELAY_ACCT、CONFIG_TASK_IO_ACCOUNTING)：未找到 - Python >= 2.5 或 Python 2.4 带有 ctypes 模块：找到
ps很少发现处于 D 状态的进程：
$ sudo ps -eo pid，用户，状态，cmd | awk'$3〜/ D / {打印$ 0}'
976 根 D [kjournald]
$ sudo ps -eo pid，用户，状态，cmd | awk'$3〜/ D / {打印$ 0}'
$ sudo ps -eo pid，用户，状态，cmd | awk'$3〜/ D / {打印$ 0}'
$
我的下一步故障排除步骤是什么？
预计到达时间：我跑了vmstat：
$ vmstat 进程 -----------内存---------- ---交换-- -----io---- -系统-- ----cpu---- rb swpd 免费 buff 缓存 si so bi bo in cs us sy id wa 0 0 3116 509372 22880 773232 0 0 18 15 24 14 2 0 97 0
该wa值 0 让我怀疑 I/O 是否真的是问题所在。
另外，是的，我知道 1.x 范围内的负载并不是真正的问题 - 但这个应用程序有不断增加负载直到阻塞的历史，如果我能在它仍然低烧的时候追踪到源头，我可能会避免死亡（打个比喻）。
答案1
我建议搜索任何非S休眠状态的进程。您可能有僵尸进程，尽管它们实际上没有执行任何操作，但可以算作正在运行的进程。 ps -eo pid,user,state,cmd | awk '$3 !~ /S/ {print $0}' 这将显示任何非休眠进程。（正在运行、等待 IO、僵尸等）
值得注意的是，您的平均负载并不令人担忧。假设您的机器有两个以上的核心，那么毫无疑问有足够的 CPU 能力可供使用。但如果您不希望在任何给定时间运行 1-2 个进程，显然仍然值得研究。——
Christopher Karel