uptime 末尾的三个数字表示 1/5/15 分钟平均负载，并不是 CPU 使用率，而是处于 R+D 状态进程的平均数量；脚本中建议读取 /proc/loadavg 以避免解析错误，同时结合逻辑 CPU 核心数判断每核负载，并重点排查 D 状态进程与 I/O 性能瓶颈。

直接查看 uptime 末尾三个数，就是 Linux 系统平均负载

如果你想快速查看 Linux 平均负载，最直接、最轻量的方法就是执行 uptime。该命令输出末尾通常会显示类似 load average: 0.42, 0.38, 0.35 的三组数字，分别代表过去 1 分钟、5 分钟、15 分钟的系统平均负载。

需要特别注意的是：平均负载并不等于 CPU 使用率，它表示单位时间内处于可运行状态（R）或不可中断睡眠状态（D）的进程平均数量。比如数值为 1.2，含义是平均有 1.2 个任务正在等待 CPU 或 I/O 资源。

常见误区包括：

• 把 top 第一行中的 %Cpu(s) 和 load average 混为一谈——两者统计维度完全不同，不能直接相互对照
• 看到 load average: 4.5 就断定 CPU 已经满载，结果 %Cpu(s) id 仍然显示 80% 空闲，实际问题往往是磁盘阻塞导致大量 D 状态进程堆积

脚本中不要解析 uptime 输出，建议直接读取 /proc/loadavg

/proc/loadavg 是 Linux 内核提供的原始负载数据来源，格式固定，例如：0.42 0.38 0.35 2/124 19876，其中前三个字段就是 1 分钟、5 分钟、15 分钟平均负载值。

为什么不建议使用 uptime | awk '{print $10}'？因为输出字段并不稳定：在中文 locale 环境中，“up” 会变成“已运行”，某些 busybox 版本还可能省略用户数，导致 $10 这类写法极易失效。

实用建议：

• 监控告警时优先取 5 分钟平均负载作为阈值参考：awk '{print $2}' /proc/loadavg
• 如果还想同时查看当前就绪队列加 D 状态进程数，可读取第四个字段斜杠前的数字：awk '{print $4}' /proc/loadavg | cut -d'/' -f1
• 该文件权限通常为 -r--r--r--，普通用户即可读取，不需要使用 sudo

负载很高但 CPU 依然空闲？重点排查 D 状态进程和 I/O 问题

如果 load average 明显高于逻辑 CPU 核心数（可通过 grep -c 'processor' /proc/cpuinfo 获取），但 top 输出中的 %Cpu(s) id 仍然较高，这通常说明系统瓶颈并不在 CPU 计算能力，而更可能卡在磁盘 I/O、网络存储或驱动层面。

排查时建议重点执行以下操作：

• 定位 D 状态进程：ps -eo stat,pid,comm | grep ' D '（前后加空格，避免误匹配到 DEAD 或 DEBUG）
• 观察磁盘响应情况：iostat -x 1，重点关注 await（大于 100ms 需警惕）和 %util（持续接近 100% 往往表示设备已饱和）
• 验证系统是否确实阻塞在 I/O：vmstat 1 5，持续观察 b 列（blocked 进程数）是否长期大于 0

不要只看单个负载数字，要结合 CPU 核心数计算“每核负载”

平均负载数字本身不能孤立判断性能问题，必须结合服务器的逻辑核心数来分析。比如一台 4 核机器上，load average: 3.8, 3.9, 3.7 说明系统较忙但通常还能承受；如果变成 5.2, 5.6, 6.1，就说明负载已经超过了承载能力，应该尽快排查。

更稳妥的做法，是计算“15 分钟每核平均负载”：awk '{print $3}' /proc/loadavg | xargs -I{} echo "scale=2; {}/$(grep -c 'processor' /proc/cpuinfo)" | bc

另外还有几个容易忽略的细节：

• 在虚拟机环境中，看到的 load average 可能偏高——因为宿主机资源竞争也可能间接反映到客户机的 /proc/loadavg 中
• htop 默认显示的 load average 条形图通常会映射成百分比效果，并非原始平均负载数值，不适合直接作为判断依据
• 在容器环境（如 Docker）中，uptime 读取的往往是宿主机负载，而容器内的 top 可能受到 cgroup 限制，因此两者显示不一致属于正常现象