众所周知，单个处理器上的1.00负载意味着有100％的负载。 类似地，四核上的4.00负载将是100％ 。
我应该如何解读4核心8线程处理器的负载？ 什么时候达到CPU的最大容量？ 在4.00或8.00 ？
1.00*n_cpu ，但主要是1.00*n_cpu 。
加载意味着以下内容：如果单CPU系统上有多个进程，它们似乎并行运行。 但事实并非如此。 实际上发生了什么事情：内核给进程一个1/100秒，然后中断它的运行。 并将下一个1/100秒传给另一个进程。
实际上，“哪一个过程应该得到我们下一个1/100秒的间隔？”这个问题将由一个复杂的启发式决定。 它被命名为任务 调度 。
当然，被阻塞的进程，例如他们正在等待他们正在从磁盘读取的数据，可以免除这个任务调度。
什么负载说：有多less进程正在等待他们的下一个1/100秒的时间框架。 当然，这是一个平均值。 这是因为您可以在cat /proc/loadavg看到多个数字。
多CPU系统的情况有点复杂。 有多个cpus，其时间框架可以给多个进程。 这使得任务调度有点 – 但不是太复杂。 但情况是一样的。
内核是智能的，它试图共享系统资源以获得最佳的效率，并且在接近那个（有一些小优化的东西，例如，如果一个进程在相同的时间运行最长的时间会更好CPU，因为caching的考虑，但他们并不重要）。 这是因为如果我们加载8，那就意味着：实际上有8个进程等待下一个时间片。 如果我们有8个cpus，我们可以把这些时间片一对一地给这个cpus，这样我们的系统将会被最优化地使用。
如果您看到top ，您可以看到实际运行的进程的数量惊人地低：它们是R标记的进程。 即使在一个不是真正的核心系统上，它也经常低于5.这部分是因为从磁盘或从networking等待数据的进程也被暂停（标记为最上面的S ）。 负载只显示CPU使用情况。
还有一些工具可以测量磁盘负载，它们至less应该作为CPU使用情况监视的重要部分，但是在我们的专业系统pipe理员世界中，它却不是那么有名。
Windows工具通常将负载与cpus的实际数量分开。 这导致一些专业的Windows系统pipe理员使用系统负载在这个分CPU意义上。 在你向他们解释这些之后，他们是不对的，而且可能会更幸福。
多核CPU实际上是同一个硅芯片上的多个CPU。 没有区别。
在超线程CPU的情况下，有一个有趣的副作用：加载一个CPU使其超线程对更慢。 但是这发生在正常任务调度处理的更深层上，尽pipe它可以（也应该）影响调度程序的stream程移动决策。
但从我们目前的观点来看，决定系统负荷的因素并不重要。
由于超线程实际上并不是第二个核心，所以它不会占用200％的内核，但是对于某些工作负载来说，它将会超过100％。
所以你的最大负载在大约4到6之间的地方是未知的
（当然这会在重载的时候变得更高，因为它实际上会计算可运行的进程，特别是当它们正在等待IO时）
平均负载并不意味着你的想法。 这不是即时CPU使用率，而是有多less进程正在等待运行。 通常这是因为很多想要CPU的东西，但并不总是如此。 一个常见的罪魁祸首是一个等待IO磁盘或networking的进程。
尝试运行ps -ev并查找进程状态标志。
state The state is given by a sequence of characters, for example, "RWNA". The first character indicates the run state of the process: D Marks a process in disk (or other short term, uninterruptible) wait. I Marks a process that is idle (sleeping for longer than about 20 seconds). L Marks a process that is waiting to acquire a lock. R Marks a runnable process. S Marks a process that is sleeping for less than about 20 seconds. T Marks a stopped process. W Marks an idle interrupt thread. Z Marks a dead process (a "zombie").
这是从ps manpage，所以你在那里find更多的细节 – R和D过程可能是特别感兴趣的。
由于种种原因，最终可能会出现平均负载“峰值”，所以除了“这个系统是否忙碌”之外，它们并不是一个很好的衡量标准。 陷入平均负载平均CPU核心不会对你有什么好处。
在Linux系统上，不仅可运行队列中的进程计算负载，而且还计算不间断睡眠状态（ 维基百科）中的进程，从而在有大量进程正在等待磁盘时导致负载高峰。
我在我们的24核Xeon系统上做了一些实验（2sockets×12核心）。 由于Linux设置超线程的方式，这种情况下的最大负载是48.0。
但是，您不能获得相当于48个内核的吞吐量。 我所观察到的是，在前24个逻辑处理器中，如果负载运行到24.0，就能获得大约90％的吞吐量。 然后，剩下的24个逻辑处理器的额外吞吐量约为10％（负载运行到48.0）。 另一种思考的方式是，如果你在24个内核上运行48个线程，如果你启用了超线程技术而不是超线程技术，那么你将获得大约10-20％的提升。 这不像营销人员暗示的那样是100％提升。
例如，testing这种观察的一种方法是运行48个线程（比如使用TBB或手动线程模型），然后运行
time numactl --physcpubind=0-23 ./myprocess
然后运行
time numactl --physcpubind=0-47 ./myprocess
后者的运行时间要less10-20％。 如果你的进程被高度I / O阻塞，那么结果可能会不同。
前者将禁止超线程，只允许线程在每个核心的单个逻辑处理器上运行，而后者将通过允许线程在（每个核心的）两个逻辑处理器上运行来启用超线程。
在这两种情况下的负载应报告为48.0 …你可以看到是非常误导。