8

尝试确定 linux 机器上的处理器队列长度（准备运行但当前未运行的进程数）。Windows 中有一个针对此指标的 WMI 调用，但对 linux 了解不多，我正在尝试挖掘 /proc 和“top”以获取信息。有没有办法确定cpu的队列长度？

编辑添加：微软关于他们的指标的话：“一个或多个准备好但由于当前正在运行的另一个活动线程而无法在处理器上运行的线程的集合称为处理器队列。”

4

4 回答 4

8

sar -q将报告队列长度、任务列表长度和三个平均负载。

例子：

matli@tornado:~$ sar -q 1 0
Linux 2.6.27-9-generic (tornado)    01/13/2009  _i686_

11:38:32 PM   runq-sz  plist-sz   ldavg-1   ldavg-5  ldavg-15
11:38:33 PM         0       305      1.26      0.95      0.54
11:38:34 PM         4       305      1.26      0.95      0.54
11:38:35 PM         1       306      1.26      0.95      0.54
11:38:36 PM         1       306      1.26      0.95      0.54
^C
于 2009-01-13T22:39:34.880 回答
5

vmstat

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  0 256368  53764  75980 220564    2   28    60    54  774 1343 15  4 78  2

第一列 (r) 是运行队列 - 我的机器上现在是 2

编辑：很惊讶没有办法只得到号码

获取数字的快速“n”脏方法（在不同的机器上可能会有所不同）：

  vmstat|tail -1|cut -d" " -f2
于 2009-01-13T20:57:34.697 回答
5

您寻求的指标存在于/proc/schedstat.

该文件的格式在内核源代码中的 sched-stats.txt 中进行了描述。具体来说，这些cpu<N>行是您想要的：

CPU statistics
--------------
cpu<N> 1 2 3 4 5 6 7 8 9


First field is a sched_yield() statistic:
     1) # of times sched_yield() was called


Next three are schedule() statistics:
     2) This field is a legacy array expiration count field used in the O(1)
    scheduler. We kept it for ABI compatibility, but it is always set to zero.
     3) # of times schedule() was called
     4) # of times schedule() left the processor idle


Next two are try_to_wake_up() statistics:
     5) # of times try_to_wake_up() was called
     6) # of times try_to_wake_up() was called to wake up the local cpu


Next three are statistics describing scheduling latency:
     7) sum of all time spent running by tasks on this processor (in jiffies)
     8) sum of all time spent waiting to run by tasks on this processor (in
        jiffies)
     9) # of timeslices run on this cpu

特别是字段 8。要查找运行队列长度，您将：

  1. 观察每个 CPU 的字段 8 并记录值。
  2. 等待一段时间。
  3. 再次观察每个 CPU 的字段 8，并计算该值增加了多少。
  4. 根据Little's Law ，将该差异除以等待的时间间隔的长度（文档说它以 jiffies 为单位，但实际上是自添加 CFS 以来以纳秒为单位），得出调度程序运行队列在该时间间隔内的平均长度。

不幸的是，我不知道有任何实用程序可以自动执行此过程，这些实用程序通常安装甚至打包在 Linux 发行版中。我没有使用它，但内核文档建议http://eaglet.rain.com/rick/linux/schedstat/v12/latency.c，不幸的是它指的是一个不再可解析的域。幸运的是，它在返程机上可用。

为什么不呢sar？vmstat

这些工具报告当前可运行进程的数量。当然，如果这个数字大于 CPU 的数量，它们中的一些肯定在等待。但是，即使进程数少于 CPU 数，进程仍可能处于等待状态，原因有很多：

  • 一个进程可能被固定到一个特定的 CPU。
  • 调度程序可能决定在特定 CPU 上调度进程以更好地利用缓存，或者出于 NUMA 优化的原因。
  • 调度程序可能故意让 CPU 空闲，以便为另一个共享相同执行核心的 CPU 上的竞争、更高优先级进程留出更多时间（超线程优化）。
  • 由于各种硬件和软件原因，硬件中断可能只能在特定 CPU 上处理。

此外，可运行进程的数量仅在瞬间采样。在许多情况下，这个数字可能会迅速波动，并且在度量被采样的时间之间可能会发生争用。

这些东西意味着可运行进程的数量减去 CPU 的数量并不是 CPU 争用的可靠指标。

于 2019-06-20T22:20:26.290 回答
2

uptime将为您提供最近的平均负载，这大约是活动进程的平均数。uptime报告过去 1、5 和 15 分钟的平均负载。这是每个系统的测量，而不是每个 CPU。

不确定 Windows 中的处理器队列长度是多少，希望它足够接近这个吗？

于 2009-01-13T20:55:36.680 回答