很多初学者会混淆几个概念。CPU繁忙程度，load。两者的区别在于，一个秘书是真的忙着抄抄写写，另一个么，反正领导只检查桌子上堆的文件数。只要桌子上准备一堆文件，在文件里换来换去就好了，没必要真的很忙。当然，大多数时候桌子上堆着很多文件的理由还是因为秘书手不够了，不过少数时候也有例外。例如fork boom，CPU很空但是load奇高。

我们就遇到了一个例外的例外。

症状是这样的。系统经常出现偶发性的load过高。例如有那么几分钟，load会高到100-200，然后就快速下降。但是检查后发现，即使在load极高的时候，cpu占用率也并不高，大概在10-20左右。磁盘吞吐也一般。那么load为什么会这么高呢？

我的第一怀疑当然是超多数量的小线程，在那里搞切换调度。所以我第一反应就是看了/proc/loadavg的当前活跃线程数——结果居然只有1-5。为了确认，我特意的持续观察了数次，在我观测期间load的1分钟计数还升高了——这说明当前实际队列比1分钟平均还要高，而活跃线程却是3。

怎么可能？交通系统报警说北三环大赛车，平均堵塞长度500辆。去一辆警车到现场回报说只看到塞了两辆，再去一辆说算上我们自己三辆。去了十多次都如此。任何脑子清楚的人都会毫无疑问的喊出——黑箱政治，政府不作为，我们要占领国会——不好意思，我们好像没有这个东西。

OK，言归正转。为了解释这个疑惑，我特意的去看了一下内核源码——我擦，loadavg的平均值计算中，是把uninterruptible算在一起的。而活跃上下文中，只算了nr_running！

——你丫敢再精神分裂点么？

为了确认，我还特意man proc，结果发现里面确实有说，平均值是R和D两者去算的。但是在活跃上下文那里，只说了the number of currently runnable kernel scheduling entities——看看清楚，这里可从没有说有D。脑子清楚的仔细想想就知道，D是不可调度的。

——问题是咱脑子不清不楚的就没想这差异，而且咱连man proc都没查。。。

另外顺便说一句，内核也告诉了我们一点东西——load计算的时候是连内核线程一起算的。

清楚这点差异后，问题的原因也很清楚了——肯定是哪里有很高的D。用ps -e Hl | grep -e R -e D扫了一下，再用wc -l做了一下统计。214个线程在D(或者R，或者只是不小心被grep到，但是实际上大部分都是D)。系统当前的loadavg正好长这样：

214.12 156.63 82.25 7/4629 10027

7个执行中线程(R)，207个uninterruptible。

——所有的谜都解开了。