我了解 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)/]$
我不明白双处理器系统上的平均负载怎么会达到 35。这对我来说似乎太高了。当我使用 top 查看进程时，系统大约有 60-70% 处于空闲状态。有人能帮忙解释一下吗？
vmstat 10 6
kthr memory page disk faults cpu
r b w 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
答案1
“负载”通常是第一列vmstat（列r，运行队列）的平均值。第一个负载的平均时间为 1 分钟，第二个负载的平均时间为 5 分钟，最后一个负载的平均时间为 15 分钟。如您所见，在您的系统中，vmstat 一度报告有不少于 102 个线程被唤醒以使用处理器（可能是一些大规模多线程应用程序）。
但不用担心，因为肯定已经处理了这一突发工作负载，并且运行队列在下一次探测时回到零并继续。V245 有两个处理器，每个处理器都是单核和单线程，因此它可以同时运行两个线程（即 r=2 意味着没有线程需要等待处理器时间）。
从统计上看可以换算成平均值为 35，但正如您所见，这个值几乎不能反映实际的系统使用情况。谚语说“三种谎言：谎言、弥天大谎和统计数据”，我认为这是一个很好的结论。
答案2
在 older-solaris 上，load-average 是可运行线程和正在运行线程的平均数。换句话说，它是 CPU 上运行的线程数加上运行队列中等待 CPU 的线程数，按时间平均。
因此... 在最后一秒内完成处理了 10 个线程的 CPU... 并且还有 5 个线程等待处理，则会显示 15。
相比之下...
Linux 平均负载被计算为 CPU 的“过载”......即在最后一段时间内，有多少线程在等待 CPU 时间，有多少线程已经完成。（以百分比表示）
因此，如果 CPU 在最后一秒内处理完了 10 个线程，并且还有 5 个线程等待处理，则显示 0.5
在 Solaris 10 中...他们稍微改变了公式...我不能 100% 确定它包含什么，但应该非常接近。
答案3
回复很晚，但接受的答案仍然有不正确的陈述，缺少部分要点，并暗示统计数据是谎言，而这里没有理由不相信操作系统报告的答案。
以下是对观察到的统计数据的深入解释。
和其他命令报告的平均负载uptime是1，5， 和15等待 CPU（运行队列）的平均线程数加上 CPU 上实际运行的平均线程数的分钟数。
这个想法是为了平滑显示通常非常不规则的运行队列大小和运行进程数。
运行队列大小是 vmstat 输出的第一列 ( r)。此处的任何非零值都意味着如果系统有更多可用 CPU，则运行速度会更快。
vmstat第一行数据显示自上次启动以来的平均值。3在您启动之前，有多少线程在您的机器上等待vmstat。这个值通常毫无意义，因为周末和其他非工作时间等长时间不活动会造成偏差：
rbw 交换免费 re mf pi po fr de sr rm s0 s2 -- in sy cs us syID 30 0 8747008 5562704 865 1866 188 63 63 0 0 -0 9 40 0 762 8588 1495 26 8 66 ↑
除倒数第二个示例显示平均数量惊人的102主题：
1021 0 7717952 4979088 0 1 0 0 0 0 0 0 112 4 0 900 3464 7683 15 976 ↑ ↑
尽管如此76％在这 10 秒的样本中处于空闲状态，这就是让您感到困惑的地方。
要理解这种明显的差异，你需要了解102是个平均的此示例的值。获取该值的一种方法是假设运行队列在一秒钟内持有 1020 个线程，然后在剩余的 9 秒内为空。任何其他导致该 102 数字的组合也是可以想象的，例如在 5 秒内有 204 个线程，而在另外 5 秒内没有线程，等等。
然而，从vmstat上一栏中，我们知道你的系统是76％在此期间空闲。一个合理的值可以容纳平均运行队列和空闲的 CPU，如下所示408线程在竞争期间2.4 秒（100％ 繁忙的 CPU）并且没有线程处于活动状态7.6 秒领先（0％ 繁忙的 CPU）。
现在我们知道肯定存在 CPU 争用。如果您有超过408CPU 可用，而不是2假设所有线程都能够全速并行运行，那么你就可以减少这些2.5 秒到周围6 毫秒。这会对交互式应用程序产生巨大影响，但对批处理作业的影响不大，因为剩余时间不会从额外的 CPU 中受益。
底线：
如果您的应用程序是交互式的，则您的系统严重超载；如果不是，则系统处于轻度超载和“正常”状态之间。
需要考虑权衡，6 毫秒对于响应时间来说可能“太好了”，而 408 CPU 又太贵了。假设60 毫秒是一个更合理的目标，40 个 CPU可能会起作用，当然如果2.5 秒很好，您的系统运行正常。
一般来说，最佳做法是假设当总体平均运行队列大小超过 CPU 数量时就会发生争用，这里是 ~37 对 2。如果不分析哪些应用程序和线程受到影响以及它如何影响平台操作，就无法确定这是否存在问题。
答案4
平均负载>>1 和高空闲百分比通常是磁盘 i/o 繁重的标志。这可能对找出原因有帮助。