直接看 uptime 的三个负载值并用 vmstat 验证，才能准确判断系统是否真忙：load 值需与 cpu 核数比较饱和度，再通过 vmstat 的 r、wa、si/so 和 us+sy 判断瓶颈类型，避免仅依赖 cpu 使用率误判。
直接看 uptime 的三个负载值，再用 vmstat 验证背后原因，就能快速判断系统是否真的“忙”——而不是只看 CPU 使用率。
先用 uptime 快速抓主干
uptime 输出末尾的 load average: X, Y, Z 是核心指标：
- 三个数分别代表过去 1 分钟、5 分钟、15 分钟的平均负载（即就绪态 + 不可中断态进程的平均数量）
- 关键不是绝对值，而是和 CPU 逻辑核数比：执行
nproc或grep -c ^processor /proc/cpuinfo获取核数 - 比如 8 核机器，load 为 6.2, 5.8, 5.5，饱和度 ≈ 6.2 ÷ 8 ≈ 77%，说明已较繁忙；若达 12.0, 10.5, 9.8，饱和度超 150%，明显过载
- 趋势比单点更重要：若 1 分钟值 > 5 分钟 > 15 分钟，说明负载正在上升；反之则在缓解
再用 vmstat 看清“忙在哪”
vmstat 1 3（每秒采样，共 3 次）能拆解负载成因：
- 关注 r 列：就绪态进程数。若持续高于 CPU 核数（如 8 核时 r ≥ 9），说明 CPU 调度队列已排队，是真实瓶颈
- 看 wa（I/O wait %）：若 > 20%，大概率磁盘慢或大量读写，进程卡在等待 I/O，此时 load 高但 us/sy 可能并不高
- 检查 si/so（swap 进出）：非零且持续，说明内存不足，系统在频繁换页，会显著拖慢响应
- 对比 us + sy：若 > 80% 且 r 也高，才是纯 CPU 计算密集型压力；若 us+sy 很低但 r 高，问题大概率不在 CPU
结合看，避免误判
Linux 负载 ≠ CPU 使用率。一个 Java 应用可能因 GC 频繁停顿（D 状态）、数据库慢查询阻塞线程、或磁盘写满导致日志卡住，都会推高 load，但 top 里 CPU 占用却不高。
- 例：
uptime显示 load 为 4.2, 3.9, 3.7（16 核机），看似健康（≈26%）；但vmstat中 r=18、wa=35%，说明有 2 倍核数的进程在等磁盘——实际已严重 I/O 瓶颈 - 再例：load 突然飙升到 10.5, 8.2, 6.1，但
vmstat的 r=0、id=95%，这时要查是不是/proc/loadavg第四字段（如 12/124）中斜杠前数字很小，说明只是瞬时唤醒，未必真压垮系统
日常建议操作
- 巡检优先跑
uptime && vmstat 1 2，10 秒内完成基础评估 - 写个简单脚本把 load 和核数自动算出百分比，比肉眼估算更准
- 对延迟敏感服务（如支付接口），把警戒线设在饱和度 0.7，别等 load > 核数才行动
- 别孤立看 top 的 %CPU ——它只反映运行中的时间片，漏掉了 D 状态和排队进程，而这正是 load 的本质
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
