uptime 是最轻量可靠的系统负载查看命令，其输出的三个斜杠分隔值分别代表1/5/15分钟平均负载，其中5分钟负载最具参考价值；/proc/loadavg 是所有工具的数据源，格式稳定、无locale干扰；负载高不等于cpu忙，需结合ps查d状态进程及iostat判断io瓶颈；真实过载需按逻辑cpu数归一化计算，虚拟机环境须宿主机交叉验证。
直接看 uptime 就够了，别绕弯
想快速知道系统当前压力水平，uptime 是最轻量、最可靠的选择。它不启动交互界面、不占额外资源，输出里那三个斜杠分隔的数字就是你要的负载值。执行后看到类似 load average: 0.42, 0.38, 0.35，就表示过去 1/5/15 分钟的平均负载。其中第二个数（5 分钟）最有参考价值——它既不过敏于瞬时抖动，也不滞后到失去时效性。
别用 top 只为查负载：它默认每 3 秒刷新一次，但你只是想“看一眼”，没必要等它渲染、加载进程列表。更别说某些终端缓存或字体渲染问题，还可能让你误读第一行的 load 字段。
/proc/loadavg 是脚本和监控的唯一可信来源
所有工具最终都从这个文件读数据，但它本身格式固定、无 locale 干扰、普通用户可读。直接运行 awk '{print $1, $2, $3}' /proc/loadavg 就能拿到三值，不会因为中文系统、busybox 版本或用户数变化而字段偏移。
- 第一列是 1 分钟负载，适合抓突发（比如刚跑完一个 rsync）
- 第二列是 5 分钟负载，告警阈值建议基于它设（例如
awk '{exit ($2 > 4) ? 1 : 0}' /proc/loadavg） - 第四列形如
2/124，斜杠前的2是当前就绪+D状态进程数，比 uptime 更实时；斜杠后是总进程数
负载高 ≠ CPU 忙，先盯 ps -eo stat,pid,comm | grep " D "
如果 uptime 显示 load average: 4.5，但 top 里 %Cpu(s) 的 id 还剩 80%，说明 CPU 根本没在干活，大量进程卡在不可中断睡眠（D 状态）——通常是磁盘 IO 卡住、NFS 挂载异常或驱动问题。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
这时候必须立刻执行：ps -eo stat,pid,comm | grep " D "（注意前后空格，避免匹配到 DATA 或 DEBUG 这类词）。再配合 iostat -x 1 看 await 是否持续 >100ms、%util 是否接近 100%。这两项同时满足，基本可以锁定是磁盘响应慢导致排队。
判断是否真过载，得算“每核负载”，不是看绝对值
负载数值本身没意义，必须结合逻辑 CPU 数。用 grep -c 'processor' /proc/cpuinfo 查出核心数（比如是 8），再拿 15 分钟负载（awk '{print $3}' /proc/loadavg）除以它：
-
≤ 0.7：空闲 -
0.7～1.0：健康 -
≥ 1.0：需关注，尤其当ps r | wc -l远小于/proc/loadavg第四列斜杠前的数字时，说明很多进程根本没进运行队列，而是死在 D 状态
虚拟机环境还要多一层验证：客户机里看到的负载可能虚高，得去宿主机上交叉比对 /proc/loadavg 和 iostat 输出。
