如何在linux中找到处理器队列长度

Question

尝试在linux机器上确定处理器队列长度(准备运行但当前不运行的进程数).Windows中有一个针对此指标的WMI调用,但对Linux不太了解我正在尝试挖掘/ proc和'top'获取信息.有没有办法确定cpu的队列长度？

编辑添加:Microsoft关于其度量标准的说法:"由于当前正在运行的另一个活动线程,已准备好但无法在处理器上运行的一个或多个线程的集合称为处理器队列."

Answer 1

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

Answer 2

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

编辑:惊讶的是没有办法获得这个数字

获得数字的快速'肮脏方式(在不同的机器上可能会有所不同):

  vmstat|tail -1|cut -d" " -f2

Answer 3

您寻求的指标存在于/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. 将该差异除以等待的时间间隔的长度（文档说它以 jiffies 为单位，但自添加 CFS 以来实际上以纳秒为单位），根据Little 定律，得出该间隔内调度程序运行队列的平均长度。

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

为什么不sar或者vmstat？

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

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

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

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

Answer 4

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

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