Shell's Home

Jun 3, 2014 - 1 minute read - Comments

为什么running不高但是load很高

很多初学者会混淆几个概念。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个执行中线程®,207个uninterruptible。

——所有的谜都解开了。

Tags: linux

台北地铁砍人事件 cgroup限定内存

comments powered by Disqus