uptime展示的三个负载数值，分别代表了过去1分钟、5分钟和15分钟内，平均处于就绪状态以及不可中断进程的数量。要判断是否存在排队情况，需要结合CPU核心数来考量。top命令能够帮助我们定位那些占用高CPU或内存的进程，以及I/O等待情况（当wa大于20%时）。在/proc/loada vg文件中，第四列的首数代表了当前处于就绪状态的进程数量。而vmstat命令中的r列反映了CPU就绪队列的情况，b列则指示了处于D状态（阻塞）的进程情况，wa、si/so这几列能够揭示I/O与内存方面的瓶颈问题。
直接看 uptime 快速确认负载趋势
若想快速了解系统的繁忙程度，uptime 是个不错的选择。它会直接输出三个数字，例如 load a verage: 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/loada vg 获取原始、无格式的负载数据
cat /proc/loada vg 返回一行五列，例如 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 的这几列才是你该盯住的地方。
