（我最初将其发布在 Stack Overflow 上 - 建议将其移至此处）。
在 Fedora 17 上，当我运行 sar 命令来查看平均负载活动时，它几乎总是显示运行队列长度为 1，即使系统处于空闲状态并且平均负载几乎为零。我对运行队列长度及其与 Linux 平均负载之间关系的理解表明，如果运行队列长度在一段时间内平均平均为 1，那么对于我的四核系统，平均负载应为 ~25% 平均负载，即我的情况是 1.00 左右：
$ sar -q 30 60
Linux 3.9.10-100.fc17.i686 (blah) 22/05/14 _i686_ (4 CPU)
16:29:10 runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
16:29:40 1 547 0.02 0.07 0.57 0
16:30:10 1 548 0.09 0.08 0.56 0
16:30:40 1 547 0.05 0.07 0.54 0
16:31:10 1 547 0.03 0.06 0.52 0
16:31:40 0 547 0.02 0.06 0.51 0
16:32:10 1 547 0.01 0.05 0.49 0
16:32:40 1 547 0.13 0.08 0.49 0
16:33:10 1 547 0.08 0.07 0.47 0
16:33:40 1 547 0.05 0.07 0.46 0
如果我经常轮询可运行的任务，我偶尔会看到弹出奇怪的进程（我使用 ps r -A | grep -v 'ps r -A' 执行此操作）。我本来希望看到一个进程定期弹出，以与 sar 输出保持一致。
然后，如果我启动一个消耗尽可能多 CPU 的单线程进程，运行队列大小会立即跳到 2（在这种情况下这是可以预料的），但奇怪的是，过了一会儿运行队列又回落到 1？
Linux 3.9.10-100.fc17.i686 (blah) 22/05/14 _i686_ (4 CPU)
16:32:40 runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
16:33:10 1 547 0.08 0.07 0.47 0
16:33:40 1 547 0.05 0.07 0.46 0
START SCRIPT
16:34:10 2 548 0.11 0.08 0.45 0
16:34:40 2 548 0.51 0.18 0.47 0
16:35:10 2 548 0.70 0.26 0.49 0
16:35:40 2 548 0.82 0.33 0.50 0
16:36:10 2 548 0.89 0.39 0.52 0
16:36:40 2 548 0.93 0.45 0.53 0
16:37:10 2 548 0.96 0.50 0.55 0
16:37:40 2 548 1.04 0.57 0.57 0
16:38:10 2 548 1.02 0.61 0.58 0
16:38:40 2 548 1.01 0.64 0.60 0
16:39:10 2 548 1.09 0.70 0.61 0
16:39:40 2 548 1.05 0.72 0.63 0
16:40:10 3 550 1.11 0.77 0.64 0
16:40:40 3 549 1.06 0.79 0.65 0
16:41:10 3 549 1.04 0.81 0.67 0
16:41:40 3 549 1.02 0.83 0.68 0
16:42:10 2 549 1.01 0.84 0.69 0
16:42:40 2 549 1.01 0.86 0.70 0
16:43:10 1 549 1.07 0.89 0.71 0
16:43:40 1 549 1.04 0.90 0.72 0
16:44:10 1 549 1.03 0.91 0.73 0
16:44:40 1 549 1.02 0.92 0.74 0
16:45:10 1 548 1.01 0.93 0.75 0
16:45:40 1 548 1.01 0.93 0.75 0
16:46:10 1 548 1.00 0.94 0.76 0
16:46:40 1 548 1.00 0.94 0.77 0
16:47:10 1 548 1.00 0.95 0.78 0
16:47:40 1 548 1.00 0.96 0.78 0
16:48:10 1 548 1.00 0.96 0.79 0
谁能解释一下这是怎么回事？我能想到的唯一解释是，如果没有别的原因，有一些特殊的系统任务可以利用CPU：
- 不包含在平均负载计算中并且
- 如果确实有需要它的进程出现，将放弃其 CPU 时间
或者
当 sar 命令对运行队列进行采样时，它会看到自身，但这并不能解释为什么运行队列最终在 cpu 加载脚本运行时保持为 1？
或者
我误解了负载平均/运行队列的概念。
任何建议非常感谢！
更新：所以我在另一台具有相同版本的 fedora 和 sar 等的机器上再次尝试。这次当系统空闲时，我看到一致的运行队列长度为 0。还在centos 5.7机器上尝试过，再次，空闲时运行队列长度始终为0。
所以大概 sar 不会立即在运行队列中看到自己。仍然无法解释为什么这台机器报告平均负载约为 0，但运行队列长度始终测量为 1。
答案1
这只是一个猜测，但如果运行队列长度不是平均值（如果已经有三个平均值，为什么应该是平均值？）而是一个时间点，那么效果很容易解释。sar在运行队列中看到的一个条目始终是sar其本身。除非你添加一个进程，否则就会有两个进程。
答案2
我得出的结论是 SAR runq_sz 是瞬时快照而不是平均值，因为
a) 我比较了 top 与 sar 每秒与低负载服务器上的最高负载平均值，当我在一分钟内平均 60 sar 每秒值时，它远远超过 top 的平均负载，但更简单。 。
b) 它始终是一个整数。如果它是平均值（甚至每秒），它将像负载平均值或 cpu 一样是小数