load average 三个数分别表示过去1/5/15分钟的平均就绪进程数，反映包括运行、等待CPU及不可中断状态（如磁盘I/O）在内的整体系统负载，而非单纯CPU使用率。
直接看 load average 三个数，别只盯着 CPU%
系统负载（load average）不是 CPU 使用率，而是单位时间里“就绪队列长度”的平均值——包括正在跑的、等待 CPU 的、以及卡在不可中断状态（比如磁盘 I/O）的进程。所以 top 或 uptime 显示的 load average: 1.23, 0.89, 0.76 这三个数，分别对应过去 1/5/15 分钟的平均就绪进程数。它比 %CPU 更早暴露瓶颈：比如磁盘卡住时 CPU 可能空闲，但 load 会飙升。
-
uptime最轻量，适合快速扫一眼；加watch -n 2 uptime每 2 秒刷新一次 -
top第一行就含 load average，同时还能看到%Cpu(s)行里的wa（I/O wait），如果 load 高但us+sy很低，wa却 >20%，基本就是磁盘拖慢了 -
cat /proc/loadavg返回五组值，前三个是 load，第四个形如2/124——斜杠前是当前运行中+不可中断状态的进程数，后是总进程数，这个瞬时值比平均值更能反映当下是否卡死
用 htop 看清哪些进程在拉高负载
htop 不是 top 的美化版，它是真正能帮你定位“谁在制造负载”的工具。默认按 CPU 排序容易误导：一个吃满 CPU 的进程 load 贡献是 1，但十个卡在 D 状态（不可中断睡眠）的进程，每个都算进 load，加起来可能贡献 10。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 启动后按
F5切换树状视图，父子进程关系一目了然，比如某个rsync进程下挂了一堆子进程，全卡在 I/O 上 - 按
F4搜索关键词，比如搜java或postgres，再看它们的状态列（S=sleeping，R=running，D=uninterruptible）——大量D是 I/O 堵塞的铁证 - 顶部条形图里，绿色是 CPU，红色是内存，蓝色是 I/O wait，颜色占比比数字更直观；如果蓝色突然变宽，而绿色没怎么动，说明 load 来自磁盘或网络阻塞
查 load 高但 CPU 不高的真实原因：vmstat 和 iostat 必须连用
只看 top 或 htop 会漏掉关键线索。load 高但 %CPU 低，常见于两种情况：一是大量进程在等磁盘，二是内核锁竞争或内存换页。这时单靠进程列表找不到元凶。
-
vmstat 1每秒输出一行，重点关注三列：r（就绪队列长度，应 ≈ load 值）、b（不可中断睡眠进程数）、wa（I/O wait 百分比）。如果r持续 > CPU 核心数，且b> 0，说明有进程卡住了 -
iostat -x 1看具体哪块盘扛不住：%util> 90% 表示磁盘饱和，await> 10ms 说明单次 I/O 响应慢，r_await/w_await分开看读写延迟 - 组合命令更高效：
vmstat 1 5 | tail -n +4 | awk '{print $1,$16}'抽出就绪进程数和 I/O wait，快速确认相关性
自动化采集 load 数据时，/proc/loadavg 比 uptime 更可靠
写监控脚本或接入 Prometheus 时，别用 uptime 解析字符串——它的输出格式在不同发行版或 locale 下可能变化（比如中文系统里“负载平均值”字样不统一）。/proc/loadavg 是内核直接提供的稳定接口，字段顺序和分隔符永远固定。
- 脚本中直接
awk '{print $1,$2,$3}' /proc/loadavg就拿到三个 load 值，无解析风险 - 注意：该文件每行只有一组数据，无需
tail -n 1；但若高频采集（如每秒一次），避免反复 open/close，可用inotifywait监听文件变更再读取 - Node Exporter 默认采集
node_load1/node_load5/node_load15，底层正是读/proc/loadavg，所以自建 exporter 时复用同一路径最稳妥
vmstat 确认 r 和 b 是否同步升高，再决定该查磁盘、查锁，还是查进程本身。 
