我有一个在Linux机器上运行一些计算密集型任务的pipe道。 启动这些脚本的脚本检查当前的负载平均值，如果高于某个阈值，则等待负载降至低于该值。 这是一个Ubuntu虚拟机（运行在Ubuntu主机上，如果这是相关的），可以为其分配不定数量的核心。 我们的开发和生产机器都是在同一物理服务器上运行的虚拟机，我们根据需要手动为每个虚拟机分配内核。
我注意到，即使VM只有20个内核，大约60的负载也不会使机器瘫痪。 我对 Linux负载平均值工作原理的理解是，高于CPU数量的任何东西都是问题的表示，但显然事情并不像所有那样清晰。
我正在考虑设置像$(grep -c processor /proc/cpuinfo) x N这里N>=1的阈值。 有没有什么聪明的办法来确定N值应该达到的最大化性能和最小化滞后？
换句话说，我怎么知道在性能开始下降之前，一台机器可以支持的最大负载平均值？ 我天真地认为是CPU的数量（所以， N=1 ），但似乎并没有阻止。 由于核心的数量可以变化，所以testing可能的组合既复杂又费时，并且由于这是由各种人使用的机器，所以是不切实际的。
那么，怎样才能决定一个可接受的最大平均负载阈值作为可用核心数量的函数呢？
负载在Linux上经常被误解。
在Linux上，测量运行或不可中断睡眠状态下的所有任务。
请注意，这是任务 ，而不是进程。 线程包含在这个值中。
负载每五秒由内核计算一次，是一个加权平均值。 那就是分钟的负荷是5/60的平均值，五分钟的5/300和十五分之五的平均值。
一般来说，没有一个参考点，作为一个纯粹的数字的负载没有什么价值，我认为这个价值经常被歪曲。
换句话说，我怎么知道在性能开始下降之前，一台机器可以支持的最大负载平均值？
这是人们在Linux中加载最常见的错误。 它可以用来衡量一些固定比率的CPU性能。 这不是什么负载给你。
详细阐述 – 人们可以很容易的理解CPU利用率。 这是随着时间的推移。 你完成工作，然后把工作分开。
在这方面可能的工作是一个固定的已知价值，通常以100的百分比表示 – 这是您的固定比率。
负载然而没有限制。 没有固定的最大值，这就是为什么你有这个困难，理解什么来衡量反对。
为了弄清什么样的负载是抽样的，确定了一个不确定的最大值，也就是当采样时系统当前存在的任务总数（这对CPU的工作没有什么影响）。
如果计算的加载没有固定的最大值，则将其join到加权平均值中，并且在测量加权时不logging任务的数量。
因为我喜欢食物，所以你可以给出的一个比喻是利用率是你能够多快地吃下你的盘子，平均而言，你有多less盘子可以吃掉。
所以，CPU效用和负载之间的差异是微妙的，但是很重要。 CPU实用程序是一项正在完成的工作的衡量标准，负载是需要完成的工作量度。
第二个谬误是Load是一个粒度测量。 您可以读取一个数字并了解系统状态。
负载不是颗粒状的，而是代表系统的一般长期状况。 不仅是每五秒钟进行一次采样（因此漏掉了在5秒钟内发生的运行任务），而是分别以1分钟，5分钟和15分钟的平均值进行测量。
你不能用它作为能力的即时测量，而是一个长期以来系统负担的一般意义。
负载可以是100，然后在30秒之后是10。 它是一个值得你一直关注的工作。
它可以给你一个系统工作趋势的想法。 它被给予超过它可以应付或更less？
由于不可中断的睡眠状态，这会将负载值浑浊为纯粹的工作调度分数 – 但是可以让您指出磁盘上有多less需求（其技术上仍需要完成的工作）。
负载也为系统上的exception提供线索。 如果你看到负载在50+，这表明有什么不对劲。
否则可能导致人们无理由担心。
我觉得负载非常具有价值，正是没有绝对的东西。 它在一个系统上的测量通常对另一个系统是毫无意义的。
它可能是我首先看到的最重要的事情之一，纯粹是为了检查一个明显的exception。 基本上我使用它几乎就像一个温度计 – 就像一个系统的一般条件而已。
我发现其采样周期对于我在系统中大部分工作负载（通常以秒为单位，而不是以分钟为单位）运行时间太长。 我想这对于执行长时间运行密集型任务的系统是有意义的，但是我并没有真正做到这一点。
我使用的另一件事是长期的容量pipe理。 在很长一段时间（几个月）内绘制图表是一件好事，因为您可以使用它来了解与几个月前相比您处理了多less工作。
最后，要回答你的问题，在你的情况下做什么。 说实话，我提供的最好的build议是，不要考虑使用负载作为什么时候运行的因素 – 用好的执行你的进程给其他进程的优先级。 这有几个原因是有好处的。
对于0（默认），每个进程的权重为1024.重量越低，CPU提供给进程的时间越less。 这是一个这种行为的表格。
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
所以比较一下，如果你有两个进程在等待运行 – 如果你修改一个进程+10，它将获得一个优先级为0的进程的大约十分之一的CPU时间。 如果你把它改成+19，它将得到优先级为0的CPU时间的1/100。
应该指出，你可能会看到你的负载在1 ，至less在你的pipe道持续时间。
我想这将是对你的问题更优雅的解决scheme。
维基百科 ：
但是，Linux还包括处于不可中断睡眠状态（通常等待磁盘活动）的进程，如果由于I / O系统繁忙或停顿导致许多进程在I / O中被阻塞，可能会导致显着不同的结果
换句话说，Linux报告的负载平均值包括任何等待I / O的进程（例如：磁盘或networking）。 这意味着如果您的应用程序在某种程度上I / O密集型，那么CPU的利用率很低（它们在等待I / O时会进入hibernate状态）的平均负载很高（例如：许多进程正在等待I / O）。
这反过来又会导致一个即使负载平均值超负荷也能够响应的系统。