大家好，我又来问问题了。load 很高， CPU 使用率很低，大家帮我分析一下原因？

今天中午吃完饭遇到的问题问题描述： dev 环境，开发忽然反映他的 docker 应用 restart 不了，也停止不了，使用 htop 直接黑屏

初步诊断： top 查看，load 28 左右，但是所有核心的 CPU 使用率那一行，idle 几乎接近 100%（是所有核心）， swap 仅剩几十 M

开始怀疑是 load 高，就先把其他吃 cpu 的程序关了试试把 load 降下来先，然后发现并没有降下来。

反而定位过程执行的诸如 ps,htop top 进一步分析，load 高的主要原因是 R （ Running ）和 D （ Uninterruptible sleep ）状态进程等待导致。 ps -eTo stat,pid,tid,ppid,comm --no-header | sed -e 's/^ *//' | perl -nE 'chomp;say if (m!^\S*[RD]+\S*!)' 发现 D 状态的就有那个无法操作的 docker 程序的 node 进程，以及前面卡死的 ps,htop 等进程。 D 状态进程是由于在等待 Io （磁盘或者网络）查看 io，没发现磁盘有大量读写出入，网络也没有机房检查硬盘，没问题，也试过写入文件和删除，都正常

这里我已觉得是磁盘有问题，但是不清楚下一步高如何去定位。

后面开发急着使用，就只能给他们重启服务器了（ D 状态进程，无法 Kill ）重启后，一切恢复正常。

请问有经验的 V2er,这种情况该如何定位下一步？我还是想了解完整的问题，或者解决问题的思路

非常感谢。

BraveRBT

2018-12-20 00:21:45 +08:00

啊哈，是一个常见问题了
这个问题来自对 load 的错误看法，我觉得确实是这样的...

其实 load 反应的并不只是” CPU 忙碌程度“，而是目前状态 R 的程序数量或者等待 I/O 的程序
关于这个的具体说明请 man proc，查看段落关键字 /proc/loadavg

其实你的猜想是部分正确的，这个问题极有可能是因为非常高的%wa 时间导致
同时也有可能是 docker daemon 尝试重启而 hang 住导致的，下次分析的时候可以看看多个维度的指标和数据

BraveRBT

2018-12-20 00:33:15 +08:00

补充上面的一句话，少说了一个词：”其实 load 反应的并不只是” CPU 忙碌程度“，而是目前状态 R 的程序数量或者等待 I/O 的程序数量之和（也就是你说的状态 D 的进程）“

另外似乎某些时候文件系统 inode 被耗尽或者磁盘满了也有可能导致这样的问题。
下次再遇到这样的问题可以试试获取更多信息研究一下，说不定就能找到问题的根本所在了。

htop/top/ps/iotop/iostat 在这些时候都能发挥作用，综合他们的数据来分析问题吧。