Linux负载是反映系统资源竞争程度的加权指标，非CPU使用率或活跃进程数；uptime显示的三个load average值分别代表过去1、5、15分钟平均就绪/不可中断进程数，D状态进程计入而S状态不计，多核需按逻辑CPU数折算，磁盘I/O阻塞可致load飙升而%CPU仍低。
Linux 的“负载”不是 CPU 使用率，也不是当前活跃进程数，而是一个加权统计的、反映系统资源竞争程度的指标。
load average 是什么，怎么看懂三个数字
执行 uptime 或 top 看到的 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。
验证方法：
Switch Modes
下载
动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。
- 用
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 压力，它是个误导性指标；优先看 iostat 的 r/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 -w、iotop、perf record -e sched:sched_switch 这类工具输出里。
