如何在“顶部”输出中解释“平均负载”？所有发行版都一样吗？

我想知道基于Red-Hat的linux的输出是否可以由基于Debian的linux进行不同的解释。

为了使问题更具体，我所要了解的是，如何理解topRed-Hat系统上命令第一行的“平均负载” 以及如何通过官方文档ro代码对此进行验证。

[有很多方法可以解决这个问题，所有这些都是可以接受的答案。]

一种可能的方法是找到正式记录此信息的位置。
另一个是找到top从我正在开发的特定发行版和版本中构建的代码版本。

我得到的命令输出是：

    top - 13:08:34 up  1:19,  2 users,  load average: 0.02, 0.00, 0.00
    Tasks: 183 total,   1 running, 182 sleeping,   0 stopped,   0 zombie
    Cpu(s):  0.2%us,  0.2%sy,  0.0%ni, 96.8%id,  2.7%wa,  0.0%hi,  0.0%si,  0.0%st
    Mem:   3922520k total,   788956k used,  3133564k free,   120720k buffers
    Swap:  2097148k total,        0k used,  2097148k free,   344216k cached

在这种情况下，如何解释负载平均值？
我设法从一个文档来源找到平均负载大约是最后一分钟，并且应将其乘以100后再由另一个文档来源进行解释。
因此，问题是：
加载量是0.02％还是2％？
文档来源和版本：

1）第一个与

    TOP(1)                        Linux User’s Manual                       TOP(1)

    NAME
           top - display Linux tasks

来源：man top在我的RedHat发行
版中，Ubuntu也具有带有“任务”的版本，该版本无法在以下位置解释平均负载：http :
//manpages.ubuntu.com/manpages/precise/man1/top.1.html

2）第二个开始于

    TOP(1)                          User Commands                         TOP(1)

   NAME         top

   top - display Linux processes

资料来源：http :
//man7.org/linux/man-pages/man1/top.1.htm

3）这开始于：

   TOP(1)

   NAME

   top - display and update information about the top cpu processes

来源：http://www.unixtop.org/man.shtml

的第一个，可以看出man top在RHEL或online ubuntu documentation和它不具有输出格式任何解释（也无法左右的平均负载在我感兴趣的） 。

在第二一个，包含了简要说明，并指出，平均负载与最后1分钟的事，但没有关于其价值的诠释！

我直接引用第二个来源：

2a。UPTIME和LOAD平均值
这部分由一行组成，该行包含：
程序或窗口名称，具体取决于显示模式的
当前时间和自上次引导以来的时间长度
用户
在最近1、5和15分钟内的系统平均负载总数

因此，如果此解释确实正确，那么仅需了解平均负载约为最后1分钟即可。
但是它没有解释数字的格式。

在第三种解释中，它表示：

指定平均负载数时，应将其乘以100。

此解释表明0.02表示2％，而不是0.02％。但这是正确的吗？另外，它是否适用于所有Linux发行版以及可能的不同实现top？
为了找到该问题的答案，我尝试通过在线搜索来遍历代码。但是我至少发现了top与RHEL相关的两个不同版本！在builtin-top.c和重构top.c。如代码开头所述，两者均受Red-Hat的版权保护，因此RHEL使用其中之一是合乎逻辑的。
http://lxr.free-electrons.com/source/tools/perf/builtin-top.c
http://lxr.free-electrons.com/source/tools/perf/util/top.c

因此，在研究那么多代码之前，我想要一个关于应该集中精力以形成对cpu负载如何解释的准确理解的意见。

从以下答案中给出的信息中，除了进行一些个人搜索之外，我还发现：

1- top我正在使用的包含在procps-3.2.8软件包中。可以使用验证top -v。
2-在procps-3.2.8我从官方网站下载的版本中，该工具似乎直接uptime从procfs文件中获取其信息/proc/loadavg（不使用linux函数getloadavg()）。
3-现在，该top命令也不使用该功能getloadavg()。我设法验证top确实与uptime显示平均负载的工具。它实际上调用uptime工具的函数，该函数从procfsfile 获取信息/proc/loadavg。

因此，所有内容都指向该/proc/loadavg文件！因此，为了对load averageby产生的内容有准确的了解top，必须阅读内核代码以查看文件loadavg的编写方式。
在其中一个答案中还指出了一篇出色的文章，该文章提供了外行对的三个值的解释loadavg。
因此，尽管所有答案都同样有用和有用，但我将标记为http://www.linuxjournal.com//article/9001的文章标记 为对我问题的“答案”。谢谢大家的贡献！

另外，从理解最高和平均负载的问题中，我找到了指向内核源代码的链接，该链接指向loadavg计算点。似乎有很多注释解释了它的工作方式，这部分代码也位于C！中。
该代码的链接是http://lxr.free-electrons.com/source/kernel/sched/loadavg.c
再次，我不打算进行任何形式的窃，只是为了完整性起见，将其添加。因此，我重复一遍，从理解最高和平均负载中的答案之一找到了指向内核代码的链接...

CPU负载是运行队列的长度，即等待运行的进程队列的长度。

该uptime命令可用于查看最后一分钟，最后五分钟和最后15分钟的运行队列的平均长度，就像通常由所显示的一样top。

较高的负载值表示运行队列很长。较低的值表示它很短。因此，如果一分钟的平均负载为0.05，则意味着在该分钟内，平均而言，运行队列中有0.05个进程正在等待运行。这不是一个百分比。这是AFAIK，在所有Unices上都是相同的（尽管有些Unices可能不计算等待I / O的进程（我认为Linux会这样）； OpenBSD（仅在一段时间内）也计算了内核线程，因此负载始终为1或更多）。

Linux top实用程序从内核获取负载值，然后将其写入/proc/loadavg。查看的来源procps-3.2.8，我们看到：

1. 要显示平均负载，请在sprint_uptime()中调用此函数top.c。
2. 此功能在生活proc/whattime.c和调用loadavg()的proc/sysinfo.c。
3. 该功能只是打开LOADAVG_FILE即可读取平均负载。
4. LOADAVG_FILE之前定义为"/proc/loadavg"。

平均负载通常由内核计算。诸如top和的应用程序uptime可以使用getloadavg(3)库调用来访问它（它可以在不同的Unix版本之间移植）。在Linux上，这通常会导致读取/proc/loadavg。在FreeBSD上，这是一个系统调用。

例如：

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>

int main()
{
  double ld[3];

  int i=getloadavg(ld,3);
  printf("Load %.2f %.2f %.2f\n",ld[0],ld[1],ld[2]);
}

uptime而top这两种作出类似的呼吁得到他们的数据。

现在1/5/15分钟的平均负载就是运行队列上的进程数。不同的操作系统可能以不同的方式进行计算。最大的区别通常是等待I / O（例如，磁盘阻塞）的进程是否可运行。在Linux上，它们是。

因此，平均负载为3.4意味着样本窗口（1、5、15分钟）内的运行队列上平均有3.4个进程。

平均负载高不一定意味着服务器过载。如果您有16个核心，则平均负载可以为16个而没有压力。您可能还会有很多应用程序fork()调用，这可能导致大量进程被创建/销毁，从而导致较高的平均负载，但又不会严重影响服务器性能。它仅应与其他指标（例如％CPU繁忙）一起用作指南。

平均负载不是特定于任何特定工具或发行版的东西，它是内核提供的度量，或更确切地说是调度程序，因此它是独立于发行的度量。测量结果记录在proc文件系统中/proc

从其解释来看，平均负载指标不是 CPU工作强度的指标，而是需要完成的工作量。我认为确实不需要将其乘以任何值，因为它是对处于可运行或不可中断状态的进程数的直接度量。

尝试查看以下两个手册页：getloadavg(3)和uptime有关更多信息。

首先，平均负载指标可能是一个很难理解的概念，我认为很多人认为这表明CPU的工作强度，但事实并非如此。