我了解Linux上的负载平均值，但是我的应用程序运行在旧式Solaris 10计算机上的负载平均值有点让人困惑。 负荷平均值似乎不可能高。 这是输出。
[netcool1 (root)/]$ uptime 11:49am up 580 day(s), 10:51, 3 users, load average: 35.50, 38.54, 39.03 [netcool1 (root)/]$ uname -a SunOS netcool1 5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Fire-V245 [netcool1 (root)/]$ psrinfo -v Status of virtual processor 0 as of: 01/11/2012 11:52:52 on-line since 06/10/2010 01:58:29. The sparcv9 processor operates at 1504 MHz, and has a sparcv9 floating point processor. Status of virtual processor 1 as of: 01/11/2012 11:52:52 on-line since 06/10/2010 01:58:27. The sparcv9 processor operates at 1504 MHz, and has a sparcv9 floating point processor. [netcool1 (root)/]$ 我不明白双处理器系统上的平均负载是多less。 这对我来说似乎非常高。 当我查看顶部的进程时，系统空闲大约60-70％。 有人可以帮忙解释一下吗？
vmstat 10 6
kthr memory page disk faults cpu rbw swap free re mf pi po fr de sr rm s0 s2 -- in sy cs us sy id 3 0 0 8747008 5562704 865 1866 188 63 63 0 0 -0 9 40 0 762 8588 1495 26 8 66 0 0 0 7715256 5068016 73 23 5 17 17 0 0 0 110 66 0 1135 3888 9855 59 12 30 0 0 0 7717936 5069128 0 5 0 6 6 0 0 0 100 4 0 1071 3273 4191 62 6 32 0 0 0 7717952 5027912 0 11649 0 5 5 0 0 0 115 21 0 1017 26370 3260 32 15 53 102 1 0 7717952 4979088 0 1 0 0 0 0 0 0 112 4 0 900 3464 7683 15 9 76 0 0 0 7717952 4978936 0 1 0 0 0 0 0 0 105 4 0 886 3379 8698 19 9 72
“负载”通常是vmstat （列r ，运行队列）的第一列的平均值。 第一次加载的平均时间是1分钟，第二次是5分钟，最后是15分钟。 正如你所看到的，在你的系统vmstat中有一个报告说不less于102个线程被唤醒使用了处理器（可能是一些大规模的multithreading应用程序）。
但是不用担心，当然，这一连串的工作量已经被处理了，下一次探测的运行队列又回到了零，并继续。 V245有两个处理器，每个单核和单线程，所以它可以同时运行两个线程（即r = 2意味着不需要等待处理器时间的线程）。
统计上这可以转化为平均35，但正如你可以看到这个值说实际的系统使用非常less。 阿达奇说“有三种谎言：谎言，该死的谎言和统计数字 ”，我认为这是一个很好的结论。
在较早的solaris上，负载平均值是可运行和正在运行的线程的平均数量。 换句话说，CPU上运行的线程数加上运行队列中的线程数，等待CPU的平均时间。
所以…一个CPU完成了10个线程的处理，最后一秒…还有5个等待处理的会显示15个。
相反…
Linux负载平均值被计算为一个CPU的“过载”…即在最后一段时间内有多less线程在等待CPU时间而已经完成了多less。 （按百分比）
所以…一个CPU完成了10个线程的处理，最后一秒…还有5个等待处理的将显示0.5
在Solaris 10中，他们改变了一下这个公式……我并不十分确定它的含义，但它应该非常接近。
相当迟的答复，但接受的答案仍然有不正确的说法，是缺less的一部分的观点，并build议统计谎言，而这里没有理由不相信操作系统报告的。
以下是对所观察统计资料的深入解释。
uptime和其他命令报告的负载平均值是等待CPU（运行队列）的线程的平均数量加上实际在CPU上运行的平均线程数的平均值的1,5和15分钟。
这个想法是平滑的显示运行队列的大小和正在运行的进程计数，这往往是非常不规则的。
运行队列大小是vmstat输出（ r ）的第一列。 这里的任何非零值意味着如果有更多的CPU可用，你的系统将运行得更快。
vmstat第一条数据行显示自上次启动以来的平均值。 启动vmstat之前，平均有3个线程正在等待您的机器。 这个价值通常是没有意义的长期不活跃时期，如周末和其他非工作时间：
r bw swap free re mf pi po fr de sr rm s0 s2 - in sy cs us sy id 3 0 0 8747008 5562704 865 1866 188 63 63 0 0 -0 9 40 0 762 8588 1495 26 8 66 ↑
所有其他样本显示一个空的运行队列，除了倒数第二个显示高达102个线程的平均数量：
102 1 0 7717952 4979088 0 1 0 0 0 0 0 0 112 4 0 900 3464 7683 15 9 76 ↑↑
在这个10秒的样本中，CPU仍然是76％的空闲，这让你感到困惑。
要理解明显的差异，您需要了解102是此样本的平均值 。 一种方法是假定运行队列在一秒钟内保持1020个线程，然后在剩余的9秒内保持空闲状态。 也可以设想任何其他的导致102号码的组合，例如在5秒钟内204个线程，在另一个5秒钟内没有线程，依此类推。
但是，从vmstat最后一栏，我们知道你的系统在这段时间里有76％空闲。 容纳平均运行队列和空闲CPU的合理值将是在2.4秒 （100％忙CPU）期间竞争的408个线程，并且在7.6秒领先（0％忙CPU）期间没有线程活动。
现在我们知道肯定有CPU的争夺。 如果你有超过408个可用的CPU而不是2个，并假设所有的线程都能够并行运行全速，那么你应该把这个2.5秒减less到大约6毫秒 。 这对交互式应用程序会产生戏剧性的影响，但对批处理作业没有太大的影响，因为剩下的时间无论如何都不会受益于额外的CPU。
底线：
如果您的应用程序是交互式的，那么您的系统将严重超载，如果不是，则会轻微超载，并且只是“常规”。
有一个折衷考虑， 6毫秒可能是“太好”的响应时间和408 CPU太昂贵。 假设60毫秒是一个更合理的目标，大约40个CPU可以完成这项工作，当然，如果2.5秒是好的，你的系统是正确的行为。
一般来说，最好的做法是假设当整体平均运行队列大小超过CPU数量时出现争用，这里大约是37比2。如果不分析哪些应用程序和线程是分析的受影响以及它如何影响平台的运作。
加载平均值>> 1和高空闲百分比通常是重磁盘I / O的标志。 这可能有助于找出原因。