如何根据可用内核数选择最大负载阈值？

负载是 Linux 上一个经常被误解的值。

在 Linux 上，它是对所有处于运行或不间断睡眠状态的任务的测量。

请注意，这是任务，而不是进程。线程包含在此值中。

负载由内核每五秒计算一次，是加权平均值。即分钟负载是 5/60、五分钟 5/300 和十五分钟 5/900 的平均值。

一般来说，负载作为一个纯数字没有参考点就没有什么价值，我认为这个值经常被歪曲。

误解 1：负载作为比率

换句话说，在性能开始下降之前，我如何知道机器可以支持的最大平均负载？

这是人们对 Linux 负载最常见的谎言。它可用于根据某个固定比率来衡量 CPU 性能。这不是负载给你的。

详细说明 - 人们很容易理解 CPU 利用率。随着时间的推移，这是实用的。您完成工作，然后将其除以可能的工作。

在这方面可能的工作是一个固定的已知值，通常表示为 100 的百分比 - 这就是您的固定比率。

然而，负载没有限制。没有固定的最大值，这就是为什么您很难理解要衡量的内容。

为了阐明什么是采样负载，确实有一个不固定的最大值，即采样时系统中当前存在的任务总数（这与 CPU 正在完成的工作没有真正的关系）。

计算的负载没有固定的最大值，因为它被放入加权平均值中，并且在测量加权时没有给出任务数量的记录。

因为我喜欢食物，所以你可以给出一个类比，即利用率是你吃盘子的速度和负荷——平均而言——你还有多少盘子可以吃。

因此，CPU 实用程序和负载之间的区别是微妙但重要的。CPU 实用程序是对正在完成的工作的衡量，而负载是对需要完成的工作的衡量。

误解 2：负载是一种即时测量

第二个谬误是负载是一种细粒度的测量。您可以阅读一个数字并了解系统状态。

负载不是粒度的，而是代表系统的一般长期条件。它不仅每五秒采样一次（因此错过了在 5 秒窗口内发生的正在运行的任务），而且分别测量为 1、5 和 15 分钟的平均值。

您不能将其用作容量的即时度量，而是在较长时期内对系统负担的一般意义。

负载可以为 100，然后仅在 30 秒后为 10。它是您必须继续观察才能使用的价值。

Load能告诉你什么？

它可以让您了解系统的工作趋势。它被给予的比它所能应付的多还是少？

• 如果负载小于您拥有的 CPU 数量（通常），则表明您的 CPU 容量大于工作量。
• 如果负载大于或等于 CPU 的数量并且呈上升趋势，则表明系统的工作量超过了它可以处理的量。
• 如果负载大于或等于 CPU 的数量并且呈下降趋势，则表明系统完成工作的速度比您给它做的事情要快。

由于不间断的睡眠状态，这确实混淆了负载值作为纯粹的工作调度分数 - 但可以让您了解磁盘上有多少需求（它仍然需要在技术上完成工作）。

负载还提供系统异常的线索。如果您看到 50+ 的负载，则表明有问题。

负载另外会引起人们无缘无故的担心。

1. 众所周知，磁盘活动会增加负载。
2. 如果大量进程绑定到一个正在等待的 CPU，负载可能会被人为夸大。
3. 具有非常低优先级（niceness）的任务通常会等待很长时间，为该特定进程增加 1 的负载。

总之

我发现 load 是一个非常模糊的值，确切地说它没有绝对值。您在一个系统上获得的测量结果通常在参考另一个系统时毫无意义。

它可能是我在顶部看到的第一件事，纯粹是为了检查明显的异常情况。基本上我使用它几乎就像一个温度计 - 就像一个系统的一般条件。

对于我投入系统的大多数工作负载（通常以秒为单位，而不是几分钟），我发现它的采样周期太长了。我认为这对于执行长时间运行的密集任务的系统是有意义的，但我并没有真正做太多。

我使用它的另一件事是长期容量管理。长时间（几个月）绘制图表是一件好事，因为您可以使用它来了解与几个月前相比您正在处理的工作量。

最后，回答你关于在你的场景中做什么的问题。老实说，我提供的最佳建议是，与其考虑使用负载作为何时运行的因素 - 使用 nice 来执行您的进程，让其他进程优先于它。这很好，有几个原因。

1. 当其他进程很忙时，你只给这个进程少量的 CPU 时间。
2. 如果 CPU 上没有任何内容或 CPU 处于空闲状态，则您的任务将 100% 的时间花在它上面。
3. 进程组中的所有进程都继承了相同的 niceness。

niceness 为 0（默认值）时，每个进程的权重为 1024。权重越低，提供给进程的 CPU 时间就越少。这是此行为的表格。

Nice  Weight
0     1024
1     820
2     655
3     526
4     423
5     335
6     272
7     215
8     172
9     137
10    110
11    87
12    70
13    56
14    45
15    36
16    29
17    23
18    18
19    15

因此，比较一下，在您有 2 个进程等待运行的情况下 - 如果您对一个进程 +10 进行调整，它将获得优先级 0 进程所具有的 CPU 时间的大约 1/10。如果您将其 renice +19，它将获得优先级 0 进程所拥有的 CPU 时间的 1/100。

应该注意的是，您可能至少在管道期间看到负载为 1。

我想这将是解决您的问题的更优雅的解决方案。

来自维基百科：

但是，Linux 还包括处于不间断睡眠状态的进程（通常等待磁盘活动），如果许多进程由于 I/O 系统繁忙或停止而在 I/O 中保持阻塞，这可能会导致明显不同的结果

换句话说，Linux 报告的平均负载包括任何等待 I/O 的进程（例如：磁盘或网络）。这意味着，如果您的应用程序在某种程度上是 I/O 密集型的，那么您的平均负载将很高（即：许多进程正在等待 I/O）而 CPU 利用率较低（它们在等待 I/O 时处于休眠状态）。

反过来，这将导致系统即使在平均负载过载的情况下也能做出响应。