Linux服务器的Load Average很高，是不是要出问题了
跑一下uptime，Load Average显示8点多，第一反应是CPU要炸了，赶紧top一看，CPU使用率却只有百分之十几，两个数字对不上，人都懵了——到底是该慌还是不该慌？
这个数字从一开始就不是"CPU使用率"
Load Average统计的是过去一段时间内，处于可运行状态（Running）和不可中断等待状态（Uninterruptible Sleep，也就是top/ps里显示的D状态）的进程平均数量。前半句"可运行状态"好理解，是真的在抢CPU的进程；后半句这个D状态才是问题所在——它指的是进程正在等磁盘、网络这类IO操作返回结果，而且这个等待不能被信号打断（内核为了保证数据一致性，故意设计成这样，比如磁盘数据还没读完，不能被其他操作插队打断）。
问题就出在这——D状态的进程根本不需要CPU，纯粹是在等IO，但Linux硬是把它算进了Load Average这个本该反映"CPU有多忙"的指标里。所以看到Load Average很高，你其实完全不知道这是CPU真的不够用了，还是磁盘/网络卡住了一堆进程在傻等，这个数字从设计上就没法单独说明问题。
为什么会这样设计，还得从1993年说起
这不是bug，是个有历史渊源的设计决定。查资料的时候翻到一个挺有意思的细节：早在1993年，Linux的设计者就讨论过这个问题，当时的逻辑是——D状态的等待通常很短暂，很快就会恢复，干脆算作"约等于在排队等CPU"。有人还做过一个很直观的验证：把系统的磁盘从快的换成慢的，Load Average会跟着涨——单纯换个慢一点的硬盘，跟CPU有没有多忙半点关系都没有，涨的完全是D状态进程数量。这个设计决定从三十多年前定下来，一直沿用到今天，也就一直带着这个容易让人误判的副作用活到了现在。
真正该看的是CPU使用率和D状态谁在唱主角
遇到Load Average偏高，先别急着断定是CPU不够用，跑一下：
1 | top |
看%us（用户进程占用）和%sy（系统进程占用）这两项，如果确实很高，那是真的CPU吃紧了；如果这两项都不高，反倒是%wa（等待IO）这一项很显眼，说明大概率是磁盘IO在拖后腿，不是CPU的问题。
想更直接地揪出到底是哪些进程在D状态里干等着：
1 | ps aux | grep " D " |
看到的进程通常是在等磁盘读写、等网络存储（比如挂载了NFS）响应，顺着这些进程往下查，能更快定位到真正的瓶颈在哪。
一个大致的判断参考
经验上，Load Average低于CPU核心数，一般不用太担心；超过核心数的70%左右，响应速度可能会开始感觉变慢；持续超过核心数好几倍，才是真正需要重视的信号。但记住这个数字终究是"运行中+等待IO"的混合体，光看这一个数字下结论，跟只看体温不看具体哪里发炎一样，容易找错方向。
之前写过的VPS的CPU使用率明明很低为什么系统还是卡和这篇讲的是两码事——那篇是CPU被虚拟化层抢走了，这篇是IO把进程卡住了，症状看着都是"感觉很卡"，但排查方向完全不一样，混着看容易把自己绕晕。