uptime是最轻量、最可靠获取1/5/15分钟平均负载的方式，其输出末尾的三个数值分别对应这三个时间窗口的就绪态（R）与不可中断睡眠态（D）进程平均数量，需结合nproc所得逻辑CPU核心数判断是否过载：持续高于1.0×核心数需关注，高于2.0×核心数大概率存在瓶颈。
系统负载不是 CPU 使用率，而是单位时间内处于就绪态（R）或不可中断睡眠态（D）的进程平均数量；直接看 uptime 或 top 顶部的 load average 数值即可，但必须结合逻辑 CPU 核心数判断是否真过载。
怎么快速拿到三个负载值（1/5/15 分钟）
最轻量、最可靠的方式就是运行：uptime。它输出末尾的 load average: X.XX, Y.YY, Z.ZZ 就是你要的全部——不需要解析、不依赖额外包、所有 Linux 发行版原生支持。
常见错误现象：有人用 cat /proc/loadavg | awk '{print $1,$2,$3}' 脚本取值，看似精确，但其实多此一举；uptime 输出稳定、字段固定、无兼容性风险。
-
uptime输出示例：19:45:22 up 12 days, 4:03, 3 users, load average: 1.25, 2.08, 2.41 - 三个数值分别对应过去 1、5、15 分钟的平均负载
- 若系统刚重启，1 分钟值可能失真，优先看 5 分钟值（更稳）
怎么确认负载高不高（关键在对比核心数）
负载为 4.0 在 8 核机器上只是中等压力，在单核机器上就是严重排队；不能只看绝对值。
获取逻辑 CPU 核心数的可靠命令是：nproc（推荐）或 grep -c ^processor /proc/cpuinfo。
- 假设
nproc返回4，而uptime显示load average: 5.12, 4.87, 4.63→ 说明过去 15 分钟内平均有约 4.6 个进程在排队，已持续超载 - 若
load average值长期 > 1.0 × 核心数，需进一步排查；> 2.0 × 核心数，大概率存在瓶颈 - 注意：负载高 ≠ CPU 满，也可能是大量进程卡在 D 状态（如磁盘 I/O 阻塞），此时
%Cpu(s)中的wa会明显升高
怎么定位是谁导致负载升高（别只盯着 %CPU）
top 默认按 %CPU 排序，但这只能发现“吃 CPU”的进程；真正推高负载的，往往是大量休眠在 D 状态的进程（比如正在读写慢盘的 rsync、数据库刷脏页、NFS 挂载卡住）。
正确做法是先看整体调度压力，再查具体进程状态：
- 运行
top，观察顶部load average和第二行%Cpu(s)中的wa（I/O wait）占比：若wa > 20%，优先怀疑磁盘或网络存储 - 按
Shift+P（大写 P）看 CPU 占用，按Shift+M看内存占用，但更要关注TASKS行里的running和sleeping数量变化 - 执行
ps aux --sort=-pcpu | head -n 5快速列出 CPU 前 5，但别忽略ps aux --sort=-stat | head -n 5—— 查看STAT列中带D的进程（不可中断睡眠）
为什么 htop 里看不到每核负载条（默认配置坑）
htop 默认把所有 CPU 合成一条 CPU average 条，掩盖了单核满载而其他核空闲的问题——这是最常被忽略的误导点。
必须手动改配置才能显示每核独立条形图：
- 启动
htop→ 按F2进 Setup → 在Available meters区域，把CPU average移出，把CPU（注意不是CPU0或CPU average）拖进Meters列表 → 按F10保存 - 或者直接写配置文件：
mkdir -p ~/.config/htop && echo "left_meters=CPU" > ~/.config/htop/htoprc && echo "right_meters=CPU" >> ~/.config/htop/htoprc - 改完后重启 htop，你会看到和逻辑 CPU 数量一致的独立条（例如 4 核 8 线程 → 显示 8 条），某条持续红色，就说明那个核被死锁或单线程霸占
真正麻烦的不是看不懂负载数字，而是误以为“全局 CPU 使用率低”就等于“系统不忙”——单核 100% + 其余核 0%，top 显示的 %Cpu(s) 可能只有 12.5%，但负载已经飙到 8.0（8 核系统）。这种错觉，必须靠每核视图打破。
