详解 top 命令中的负载含义

凌晨三点被PagerDuty吵醒，眯着眼SSH进服务器，top命令一敲，看到load average: 8.52, 6.31, 4.11。第一反应是"CPU炸了"，可定睛一看，%Cpu(s)那行赫然写着60%id。这种割裂感几乎每个运维都经历过——负载高不代表CPU忙，CPU闲也不代表系统轻松。

Load Average 不是 CPU 使用率，而是"排队压力"

很多人把 top 首行的 load average 简单粗暴地理解为"CPU 占用率"，这是天大的误会。这三个数字分别代表过去 1 分钟、5 分钟、15 分钟内，处于可运行状态（R）和不可中断睡眠状态（D）的进程平均数量。说白了，它衡量的是"想干活但干不成"的进程排队长度，而不只是"正在干活"的。

linux 内核把进程状态分得极细。R（Running/Runnable）好理解，就是要么在 CPU 上跑，要么在就绪队列等 CPU。但 D（Uninterruptible Sleep）状态常被忽略——这是进程在等待磁盘 I/O、网络存储响应，或者某些硬件信号，连 kill -9 都杀不死。当数据库刷盘、日志写入阻塞、NFS 挂载卡死时，D 状态进程堆积，负载值就会飙高，哪怕 CPU 在Idle 喝茶。

三档时间的"趋势密码"

top 里三个数字的排列顺序暗藏玄机。如果 1 分钟值（8.52）远高于 15 分钟值（4.11），说明系统压力在急剧恶化；反过来，如果 1 分钟值低于 15 分钟值，意味着刚才的洪峰正在退去。理想状态下，负载值应该低于 CPU 核心数（比如 8 核机器长期低于 8），但这也不是铁律——密集型 IO 场景下，负载 20 而 CPU 占用 30% 是常态。

排查时别只看数字，要按 1 键展开每个 CPU 的详情，再结合 iostat -x 1 看 %util 和 await。如果磁盘队列（aqu-sz）爆满而 CPU 很闲，那高负载的罪魁祸首就是存储子系统，不是算力不够。

记住，load average 是系统繁忙程度的"体温计"，不是"病因"。看到数字异常时，先 ps aux | grep D 抓出那些卡在 D 状态的"僵尸进程"，往往比盲目加 CPU 核数有用得多。