uptime末尾三个数字是系统负载平均值，表示单位时间内处于R（运行/就绪）或D（不可中断睡眠）状态的进程平均数量，并非CPU使用率。
直接看 uptime 末尾的三个数字，就是系统负载平均值；但只读这个数字没用，必须结合 CPU 核心数和进程状态才能判断是否真有问题。
为什么 uptime 显示的 load average 不是 CPU 使用率
这三个数（如 1.23, 0.98, 0.75）表示单位时间内处于以下两种状态的进程（线程）平均数量：
- R 状态：正在运行或就绪等待 CPU 调度
- D 状态：不可中断睡眠，通常卡在磁盘 I/O、NFS 或驱动上
它们来自内核的指数加权移动平均（EWMA），每 5 秒采样一次。所以：
-
1.23（1 分钟）对突发最敏感，可能只是临时脚本 -
0.98（5 分钟）最稳定，是日常巡检的核心参考值 -
0.75（15 分钟）衰减慢，反映长期压力趋势
常见误解：load average: 4.5 且 %Cpu(s): 92% id —— 这说明大量进程卡在 D 状态，CPU 其实很空，但 I/O 已堵死。
怎么查当前 CPU 核心数并判断负载是否合理
负载数值本身无意义，必须和逻辑 CPU 数对比。执行：
grep -c 'processor' /proc/cpuinfo
假设输出是 4，那：
-
load average: 0.3, 0.4, 0.5→ 正常，远低于 4 -
load average: 3.8, 3.9, 3.7→ 忙，但尚可接受 -
load average: 5.2, 5.6, 6.1→ 持续超载，需排查
更严谨的做法是算“每核负载”：15 分钟值 ÷ 核心数：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- ≤ 0.7：空闲
- 0.7～1.0：健康
- ≥ 1.0：需关注
- > 1.2：建议立即查
ps -eo stat,pid,comm | grep " D "
别信字段位置，用 /proc/loadavg 直读最稳
想写监控脚本？千万别用 uptime | awk '{print $10}' —— 字段会漂移（比如中文 locale、busybox 版本、用户数变化都会导致错位）。
正确做法是直读内核源文件：
awk '{print $1, $2, $3}' /proc/loadavg
它固定返回五列，前三个就是 1/5/15 分钟负载，格式永远一致。第四个字段（如 2/124）中斜杠前的数字是当前就绪+不可中断进程数，比 uptime 更实时。
如果要取 5 分钟值做告警阈值，就用：
awk '{print $2}' /proc/loadavg
看到负载高之后，下一步该盯什么
uptime 只告诉你“有排队”，不告诉你“谁在排、排什么”。接下来必须分情况：
- 如果
load高 +%Cpu(s) us也高 → 用top按P排序找高 CPU 进程 - 如果
load高 +%Cpu(s) id高 +iostat -x 1中%util ≈ 100%→ 查磁盘瓶颈 - 如果
cat /proc/loadavg第四字段斜杠前数字远大于ps r | wc -l→ 大量 D 状态进程，基本锁定 I/O 层问题
最容易被忽略的一点：很多团队把 1 分钟负载 当成唯一指标，结果错过缓慢爬升的趋势。真正危险的是 0.9, 1.4, 2.0 这种递增组合——它意味着问题正在积累，而不是刚爆发。
