Linux 的 Load Average 是什么？为什么 CPU 使用率不高，系统负载却很高？

知识点详解：忙着计算，和排队等资源，有什么不同？

CPU 使用率描述已经消耗的时间

假设处理器持续执行计算，它的使用率会升高。很多任务同时需要 CPU，超出可同时执行的能力，任务就会等待调度。

这时负载需求可能很高，CPU 使用率也高。但 CPU 使用率有百分比上限，排队任务数量可以继续增长。两者不是同一量纲。

讨论全机平均使用率时，还要确认工具是按单核还是按多核汇总，不能把不同显示口径直接比较。

Linux 把哪些任务计入负载？

可运行状态包含正在执行与准备运行的任务。Linux 还计入不可中断等待状态，常见工具中可观察到 D 状态。

这类等待经常与 I/O 有关，但不能把所有 D 状态都解释成磁盘读写，也不能把所有正在等待网络或锁的线程都算进去。很多普通可中断休眠并不属于这个统计范围。

因此大量任务卡在相关等待路径上时，CPU 可能并不忙，负载却很高。Linux /proc/loadavg 说明

三个负载数字怎样读？

1、5、15 分钟是不同的平滑尺度。短尺度高于长尺度，通常提示近期需求在上升；短尺度低于长尺度，则可能正在回落。

它们不是把“刚好过去一分钟”每一秒的任务数简单求平均，变化也不会在任务停止后瞬间清零。具体计算可参见 Linux loadavg 源码。

所以一次截图不能完整说明问题。需要与故障发生时间、任务状态和延迟趋势对照。

为什么负载除以核数也不是 CPU 百分比？

如果已知是 CPU 密集任务，负载与可用 CPU 数量的关系可以帮助判断争用。但负载包含其他等待，任务本身也可能受到绑核、容器配额和调度限制。

八核机器负载为 8，不代表每个核恰好 100% 使用。一个单线程热点可能压满一核，而全机平均 CPU 仍不高；另一个高负载系统则可能在等待存储。

先确认瓶颈类型，再谈扩容。等待外部存储的任务增加，未必通过增加 CPU 就能解决。

排查顺序怎么安排？

先观察负载和业务延迟是否同步变化，再看 CPU 与可运行任务队列。如果 CPU 不忙而 D 状态多，继续检查具体进程和等待路径。

只读工具可以辅助：

uptime
vmstat 1
iostat -xz 1
ps -eo pid,stat,wchan:32,comm

这些命令需要对应 Linux 工具和权限；输出含义也要结合设备和系统判断。本文未执行目标 Linux 故障实验。

单个 iowait 或设备利用率同样不能证明根因。还应检查服务线程、磁盘或网络存储延迟，以及容器限制，必要时使用更具体的性能诊断。

面试官继续追问

Load 很高，重启就能解决吗？

可能暂时减少任务，但不代表找到等待原因。重启也可能破坏现场，应按应急流程保留必要证据。

普通 sleep 会让负载升高吗？

不能把所有休眠都算进去。要看任务状态是否属于负载统计范围。

只用 Load Average 自动扩容可以吗？

要先证明它与业务瓶颈相关。配额、I/O 等待和外部依赖都可能让这个信号失真，通常需要结合吞吐、排队和延迟。

面试速记卡

• CPU 使用率：处理器时间有多忙。
• Linux 负载：可运行任务＋不可中断等待形成的需求。
• 三个数字：不同时间尺度的平滑趋势，不是严格窗口平均。
• 高负载低 CPU：检查任务状态与等待路径。
• 判断背景：CPU 数量、容器配额、I/O 与业务延迟。