Linux怎么查看系统的详细负载情况

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 的这几列才是你该盯住的地方。