Bar*_*ski 14 linux central-processing-unit
众所周知,单个处理器上的负载为1.00意味着有100%的负载。类似地,四核上的4.00负载将是100%。
我应该如何解释 4 核 8 线程处理器上的负载?我什么时候达到 CPU 的最大容量?在4.00或8.00?
pet*_*erh 17
不确定,但主要是在1.00*n_cpu.
负载的含义如下:如果在单 CPU 系统上有多个进程,它们似乎是并行运行的。但事实并非如此。实际发生的情况:内核为进程提供 1/100 秒,然后通过中断中断其运行。并将下一个 1/100 秒交给另一个进程。
实际上,“哪个进程应该获得我们的下一个 1/100 秒间隔?”的问题将由复杂的启发式算法决定。它被命名为任务 调度。
当然,被阻塞的进程,例如他们正在等待他们从磁盘读取的数据,不受此任务调度的影响。
负载说明:当前有多少进程正在等待它们的下一个 1/100 秒时间范围。当然,这是一个平均值。这是因为您可以在一个cat /proc/loadavg.
多 CPU 系统中的情况稍微复杂一些。有多个 CPU,其时间范围可以分配给多个进程。这使得任务调度有点复杂——但不是太多。但情况是一样的。
内核是智能的,它试图共享系统资源以获得最佳效率,并且接近于这一点(有一些小的优化事情,例如如果一个进程在同一个进程上运行尽可能长的时间会更好cpu 因为缓存的考虑,但它们在那里并不重要)。这是因为如果我们有负载 8,这意味着:实际上有 8 个进程在等待它们的下一个时间片。如果我们有 8 个 cpu,我们可以将这些时间片一对一地分配给 cpu,这样我们的系统就会得到最佳使用。
如果您看到top,您可以看到实际运行的进程数量出奇地少:它们是由R那里标记的进程。即使在一个不是真正的核心系统上,它也经常低于 5。这部分是因为等待来自磁盘或网络数据的进程也被挂起(用S顶部标记)。负载仅显示 CPU 使用率。
也有测量磁盘负载的工具,恕我直言,它们至少应该作为 cpu 使用情况监控很重要,但不知何故,它在我们的专业系统管理员世界中并不那么为人所知。
Windows 工具通常将负载除以 CPU 的实际数量。这导致一些专业的windows系统管理员使用这种分cpu意义上的系统负载。他们不对,你向他们解释后可能会更快乐。
多核 CPU 实际上是同一硅芯片上的多个 CPU。没有区别。
在超线程 CPU 的情况下,有一个有趣的副作用:加载 CPU 会使其超线程对变慢。但这发生在正常任务调度处理的更深层次上,尽管它可以(并且应该)影响调度程序的进程移动决策。
但从我们目前的观点来看——什么决定了系统负载——这也无关紧要。
由于超线程实际上并不是第二个核心,因此它永远不会使核心达到 200%,但对于某些工作负载,它会使其超过 100%。
所以你的最大负载大约在 4 到 6 之间未知
(当然,当过载时,这个值可能会更高,因为它实际上计算了可运行的进程,特别是当它们正在等待 IO 时)
平均负载并不意味着你认为它意味着什么。这不是关于即时 CPU 使用率,而是关于有多少进程正在等待运行。通常这是因为很多东西都需要 CPU,但并非总是如此。一个常见的罪魁祸首是等待 IO 的进程——磁盘或网络。
尝试运行ps -e v并查找进程状态标志。
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").
Run Code Online (Sandbox Code Playgroud)
这是从ps手册页,让你找到一个更详细的有-R和D过程可能是特别感兴趣的。
由于各种原因,您最终可能会遇到负载平均“峰值”,因此除了“此系统是否繁忙”之外,它们并不是衡量其他任何事情的好方法。陷入将平均负载映射到 CPU 内核的困境对您没有任何好处。