* nix机器上的“负载平均值”是“运行队列的平均长度”，换句话说，是正在做某事（或等待某事）的进程的平均数量。 虽然这个概念很简单，但是要解决这个问题并不那么直截了当。
以下是我今天工作的服务器上的统计信息，这让我想知道解决这类问题的最佳方法。 统计数据如下：
我最终通过重新启动MySQLd来“修复”这个问题，这并没有什么意义，因为根据mysql的“show processlist”命令，服务器在理论上是空闲的。
我应该使用哪些其他工具/指标来帮助诊断此问题，并可能确定导致服务器负载运行如此之高的原因？
这听起来像你的服务器IO绑定 – 因此进程坐在D状态。
使用iostat查看磁盘上的负载。
如果MySQL导致大量的磁盘search，那么考虑把你的MySQL数据放在一个完全独立的物理磁盘上。 如果它仍然很慢并且是主从设置的一部分，则也应将复制日志放到单独的磁盘上。
请注意，单独的分区或逻辑磁盘是不够的 – 磁头寻道时间通常是限制因素，而不是数据传输速率。
负载平均为25，只有2-3个进程请求CPU的声音有点奇怪。 25的加载意味着你的系统中有25个处于Running（R）或Uninteruptable（D）状态的进程。 有些评论注意到ps aux中没有显示的线程被计算为运行队列中的活动进程。 您可以看到与ps axms线程。 这取决于所使用的系统是如何计算在负载中的。
但是，真正重要的是要知道。 负载与CPU利用率无关。 如果每个进程只使用1％的CPU，然后阻止你的平均负载也是25。
所以我的猜测是，当你的负载达到25时，你有太多需要io的进程，而不能得到它。 所以他们阻止并正在等待input或写入访问。 他们都落在实际的排队，你的负荷推高。
如果你只有2-3个进程在线，请注意线程。 如果进程和/或线程在给定的时间段内总和为25，那么您的系统只能达到25的平均负载。
如果这是不断的，你有一个问题。 如果每天只有一两次，请注意IO昂贵的cronjobs并修改它们执行的时间。
另一个问题可能是脚本或程序在给定的时间启动25个线程或进程，这些进程或线程互相阻塞。 我猜你在给定的时间CPU利用率也是非常高的，系统并不能满足目前所要求的所有请求。
如果你的内核> 2.6.20，我build议通过vmstat的iotop。 iotop在视图中显示系统的最佳IO。 也许这会帮助你。
显示CPU使用率和进程的另一个好工具是htop。 它显示了每个cpu的CPU利用率，作为一个小图，所有三个负载+当前使用的mem和swap空间的graphics条。
回顾这六年后，我意识到这里没有任何答案是有用的。 这是迄今为止最简单的方法，可以查看Linux上的平均负载：
# View processes and threads affecting load average ps auxH | grep -v " S"
只有3个正在运行的进程可以获得25的平均负载的原因是每个线程单独计算负载平均值。 ps的H选项显示线程，就好像它们是进程一样。
你没有空间不足，是吗？ 你提到没有硬件问题，大量的免费内存等等。或者没有更多的自由空间（可能在/ var？）或者你的MySQL数据库挂载在远程驱动器上，并且有networking问题。
在这样的情况下，我喜欢让Munin或类似的服务器来监视服务器。 这样你就可以得到一个以图表的forms表示的历史，这可能会很好地给出在什么地方负载最初开始显示自己的提示。而且，默林默认安装了一系列的预处理testing。