uptime显示的三个负载值分别代表1/5/15分钟平均就绪+不可中断进程数，需结合cpu核心数判断是否排队；top可定位高cpu/内存进程及i/o等待（wa>20%）；/proc/loadavg第四列首数为当前就绪进程数；vmstat中r列反映cpu就绪队列，b列指示d状态阻塞，wa、si/so揭示i/o与内存瓶颈。
直接看 uptime 快速确认负载趋势
想一眼知道系统是不是“忙”，uptime 是最快路径。它不加修饰地输出三个数字，比如 load average: 1.25, 0.98, 0.73 —— 分别对应过去 1、5、15 分钟的平均负载。这不是 CPU 使用率，而是“就绪态 + 不可中断态（D 状态）进程”的平均数量。
关键判断依据是逻辑 CPU 核心数：nproc 或 grep -c ^processor /proc/cpuinfo 查出来是 4，那负载长期 > 4 就说明有排队；若 1 分钟值（1.25）明显高于 5/15 分钟值，说明压力刚上来，得立刻查进程。
用 top 关联负载和具体进程
top 启动后顶部第一行就复用 uptime 的负载数据，但真正有用的是它能帮你把高负载“落地”到具体进程上：
- 按
P（大写）按 %CPU 降序，看谁在猛吃 CPU - 按
M按内存排序，内存不足会触发 swap 和 D 状态进程，间接推高负载 - 重点看
%Cpu(s)行里的wa：如果 >20%，说明大量进程卡在 I/O 等待，不是 CPU 不够，而是磁盘慢或 NFS 卡住 - 注意
Tasks行中running和sleeping的比例——如果running持续 ≥ CPU 核心数，队列已在积压
读 /proc/loadavg 获取原始、无格式的负载数据
cat /proc/loadavg 返回一行五列，例如 1.25 0.98 0.73 2/864 12345：
- 前三列同
uptime，是 1/5/15 分钟负载 - 第四列
2/864中斜杠前的2是当前就绪态进程数（r 列），斜杠后是总进程数；这个2如果长期 > CPU 核心数，说明调度器一直在排队 - 第五列是最近创建的 PID，对排查瞬时爆发的 fork 洪水有用
- 脚本采集时优先用这个文件，没空格、没换行、无解析成本
靠 vmstat 1 看清负载背后的资源瓶颈
vmstat 1 每秒刷新一次，比 top 更底层，能区分“真忙”和“假忙”：
-
r列：就绪队列长度，直接对应负载定义中的“可运行进程数”；持续 > CPU 核心数 = CPU 真饱和 -
b列：不可中断睡眠进程数（D 状态）；如果b高而r低，说明进程卡在磁盘、NFS 或内核锁里，不是 CPU 问题 -
wa列：I/O 等待占比；配合iostat -x 1看%util，>90% 就基本锁定磁盘瓶颈 -
si/so非零？说明内存不足，swap 开始拖慢整个调度链路
负载高从来不是孤立数字，它背后要么是 CPU 在抢，要么是磁盘在堵，要么是内存在抖——vmstat 的这几列才是你该盯住的地方。
