Linux 运维中“负载”的正确理解方式

11次阅读

linux负载是反映系统资源竞争程度的加权指标,非CPU使用率或活跃进程数;uptime显示的三个load average值分别代表过去1、5、15分钟平均就绪/不可中断进程数,D状态进程计入而S状态不计,多核需按逻辑CPU数折算,磁盘I/O阻塞可致load飙升而%CPU仍低。

Linux 运维中“负载”的正确理解方式

Linux 的“负载”不是 CPU 使用率,也不是当前活跃进程数,而是一个加权统计的、反映系统资源竞争程度的指标。

load average 是什么,怎么看懂三个数字

执行 uptimetop 看到的 load average: 1.23, 0.98, 0.76 分别代表过去 1、5、15 分钟的平均负载值。这个值是“就绪队列长度”的时间加权平均——即平均有多少进程在等待 CPU(或不可中断状态等待 I/O)。

关键点:

  • 它不区分 CPU 密集型还是 I/O 密集型进程;D 状态(uninterruptible sleep)进程算入,S 状态(sleeping)不算
  • 单核 CPU 下,负载 = 1.0 表示理论满载;多核需按逻辑 CPU 数折算(如 4 核服务器,负载
  • 负载长期 > CPU 核数 × 1.5,说明存在明显资源争抢,需排查

为什么磁盘卡住会让 load 飙升,但 %CPU 很低

当大量进程卡在 D 状态等待磁盘响应(比如 NFS 挂载点卡死、坏块读取、RaiD 同步中),它们不消耗 CPU 时间,所以 %CPU 看起来很低,但全在就绪/不可中断队列里,直接推高 load average。

验证方法:

  • ps aux --sort=-pcpu | head -10 看不到高 CPU 进程,但 ps aux --sort=-state | head -10 会看到一堆 D
  • iostat -x 1 查看 %util 是否持续 100%,await 是否异常高
  • cat /proc/loadavg 第四个字段是当前 D 状态进程数,可直观看是否突增

load 和 CPU idle、%iowait 的关系容易混淆

%iowait 是 CPU 在“有空闲且在等 I/O 完成”时的占比,它依赖于 CPU 处于 idle 状态;而 load 统计的是所有等待中的进程,不管 CPU 是否空闲。两者无直接换算关系。

典型反例:

  • 一个慢速磁盘上跑 100 个并发 dd%iowait 可能只有 20%(CPU 大部分时间在忙调度和上下文切换),但 load 可达 80+
  • CPU 被单个计算密集型进程 100% 占满时,%iowait=0,但 load ≈ 1(仅该进程在运行队列)

不要用 %iowait 判断 I/O 压力,它是个误导性指标;优先看 iostatr/s, w/s, await, svctm/proc/loadavg 的第四个数。

监控时 load 值多少才算异常

没有绝对阈值,必须结合 CPU 核心数和业务特征判断:

  • 短时 spike(如每小时一次备份)导致 load 达 3×CPU 核数,只要持续时间
  • Web 服务常见模式:load 在 0.3~1.5 之间波动属正常;若稳定在 >2.0 且伴随请求延迟上升,应查瓶颈
  • 注意容器环境:cgroup 限制下,宿主机 load 可能被虚高(多个容器共用 CPU quota),此时更应关注 cpu.stat 中的 nr_throttled

最容易被忽略的是:load 是系统级指标,无法定位具体服务;它只是“警报灯”,真正的问题往往藏在 pidstat -wiotopperf record -e sched:sched_switch 这类工具输出里。

text=ZqhQzanResources