Linux 系统负载平均值，是指过去 1/5/15 分钟内处于可运行状态或不可中断状态的进程平均数量，并不是 CPU 使用率；判断负载高低时，必须结合 CPU 核心数综合分析，推荐直接读取/proc/loadavg 来获取更稳定、准确的数值。
直接看 uptime 末尾三个数，但不要只盯着数字本身
获取到这三个数值后（例如 0.42, 0.38, 0.35），它们分别表示 Linux 系统 1 分钟、5 分钟和 15 分钟的负载平均值。不过要注意，脱离 CPU 核心数单独看这些数字，并不能准确判断系统压力。比如服务器有 4 个逻辑 CPU 核心，那么当负载达到 load average: 5.2, 5.6, 6.1 时，通常才说明系统已经进入持续高负载甚至超载状态；相反，如果数值长期保持在 1.2, 1.0, 0.9 左右，则通常说明系统运行较为平稳、健康。
常见误区是：把 uptime 输出中 load average 后面的三个数字误认为 CPU 使用率。实际上，它既不是百分比，也不是系统进程总数，而是“平均有多少任务正在等待 CPU 调度或等待 I/O 完成”的指标。
脚本中不要用 uptime | awk '{print $10}' 提取负载
因为字段位置并不固定：在中文 locale 环境下，“up” 可能显示为“已运行”，再加上在线用户数变化、busybox 版本不同等因素，都会导致 $10 取值错误。更稳妥、更适合脚本和监控系统的方式，是直接读取内核提供的源文件：
awk '{print $2}' /proc/loadavg—— 稳定获取 5 分钟负载值，适合用于告警阈值判断cat /proc/loadavg输出固定五列：0.42 0.38 0.35 1/1234 12345，前三列就是系统负载平均值，第四列斜杠前的数字（如1）表示当前处于就绪态 + 不可中断态的进程数，比uptime的信息更实时/proc/loadavg权限通常是-r--r--r--，普通用户也可以直接读取，无需使用sudo
负载很高但 %Cpu(s) id 依然很高？重点排查 D 状态进程
这是 Linux 系统运维中非常容易忽视的一类典型误判：例如系统负载达到 4.5，但 CPU idle 仍然有 80%，这往往意味着并不是 CPU 真正繁忙，而是有大量进程卡在不可中断睡眠（D 状态），常见原因通常集中在磁盘 I/O、NFS 挂载或驱动层问题。
可以立即执行以下命令进行排查：
ps -eo stat,pid,comm | grep " D "—— 查看当前处于 D 状态的进程vmstat 1 5查看b（blocked 进程数量）和wa（I/O wait 百分比）iostat -x 1观察%util是否长时间接近 100%
如果 /proc/loadavg 第四个字段中斜杠前的数字（例如 23/124 里的 23）明显大于 ps r | wc -l 的结果，基本可以判断问题更可能出在 I/O 层，而不是 CPU 本身。
top 和 htop 显示的 load average 为什么有时与 uptime 不一致
虽然这三者本质上读取的都是同一个内核文件 /proc/loadavg，但它们的展示逻辑并不完全一样：uptime 只输出一次静态快照；top 默认按 3 秒周期刷新；而 htop 如果启用了 CPU 百分比映射（路径：F2 → Display Options → Show CPU average），可能会把负载值转成条形图展示，这种可视化形式很容易让人对数值产生误读。
另一个更隐蔽的差异常见于容器环境：宿主机执行 uptime 读取的是全局系统负载，而容器中的 top 可能因为 cgroup 限制，只能看到被约束后的部分数据。如果需要严格对比不同环境下的 Linux 负载平均值，统一使用 cat /proc/loadavg 通常最可靠。
此外，最容易被忽略的其实是负载的时间趋势：如果只盯着 1 分钟负载值，往往会错过系统压力缓慢上升的过程。相比一次短暂的 1 分钟突刺，15 分钟负载值持续高于 1.0 且不断上升，通常更值得及时干预和排查。
