*nix 机器上的“平均负载”是“运行队列的平均长度”，换句话说，就是正在执行某项操作（或等待执行某项操作）的进程的平均数量。虽然这个概念很容易理解，但解决问题却不那么简单。
以下是我今天工作的服务器上的统计数据，这让我想知道解决此类问题的最佳方法。以下是统计数据：
- 1GB 可用 RAM，0 交换空间使用量
- CPU 时间大约 20％ 用户，30％ 等待，50％ 空闲（根据 top）
- 大约有 2 到 3 个进程同时处于“R”或“D”状态（使用 ps | grep 进行测试）
- 服务器日志中没有任何表明硬件问题的错误消息
- 平均负载约 25.0（针对所有 3 个平均值）
- 服务器明显对用户无响应
我最终通过重新启动 MySQLd 来“解决”了该问题......但这没有多大意义，因为根据 mysql 的“show processlist”命令，服务器理论上处于空闲状态。
我应该使用哪些其他工具/指标来帮助诊断这个问题，并确定导致服务器负载如此之高的原因？
答案1
听起来您的服务器受到 IO 限制 - 因此进程处于D停滞状态。
用于iostat查看磁盘上的负载。
如果 MySQL 导致大量磁盘寻道，则考虑将 MySQL 数据放在完全独立的物理磁盘上。如果速度仍然很慢并且是主从设置的一部分，则将复制日志也放在单独的磁盘上。
请注意，单独的分区或逻辑磁盘是不够的 - 磁头寻道时间通常是限制因素，而不是数据传输速率。
答案2
6 年后再回过头来看这个问题，我意识到这里的答案根本没什么用。这是迄今为止最简单的查看 Linux 上哪些因素影响了平均负载的方法：
# View processes and threads affecting load average
ps auxH | grep -v " S"
仅运行 3 个进程就能获得 25 的平均负载，这是因为每个线程都单独计入平均负载。该H选项可将ps线程显示为进程。
答案3
平均负载为 25，而请求 CPU 的进程只有 2-3 个，这听起来有点奇怪。负载为 25 意味着系统中始终有 25 个进程处于运行 (R) 或不可中断 (D) 状态。一些评论指出，ps aux 中未显示的线程被计为运行队列中的活动进程。您可以使用 ps axms 查看线程。它们在负载中的准确计数取决于所使用的系统。
但真正重要的是要知道。负载与 CPU 利用率完全无关。如果每个进程仅使用 1% 的 CPU，然后阻塞，则平均负载也为 25。
所以我的猜测是，当负载增加到 25 时，有太多进程需要 io 却无法获得。因此它们被阻塞并等待输入或写入访问。它们都进入实际运行队列，负载就会增加到这个高度。
如果您只有 2-3 个进程处于活动状态，请注意线程。如果在给定时间段内进程和/或线程总数为 25，则系统只能达到 25 的平均负载。
如果这种情况持续发生，则说明您有问题。如果这种情况每天只发生一两次，请留意 IO 消耗大的 cronjob 并修改其执行时间。
另一个问题可能是脚本或程序在给定时间启动 25 个线程或进程，而这些进程或线程相互阻塞。我猜你在给定时间的 CPU 利用率也很高，系统无法满足此时提出的所有请求。
如果您的内核版本 > 2.6.20，我建议使用 iotop 而不是 vmstat。iotop 会以类似 top 的实时视图向您显示系统的当前 IO。也许这会对您有所帮助。
另一个显示 CPU 使用率和进程的出色工具是 htop。它以小图的形式显示每个 CPU 的 CPU 利用率、所有三个负载 + 当前使用的内存和交换空间的图形条。
答案4
在这种情况下，我喜欢穆宁或类似方法，监控相关服务器。这样，您便可以得到以图表形式呈现的历史记录，这很可能很好地提示负载最初在哪个区域开始显现。此外，Munin 的默认安装附带了一套很好的预测试。