load average需与cpu核心数比较，若比值＞0.7说明任务排队；wa＞20%表明i/o等待严重，二者共同指示系统变慢根源而非cpu占用率。
top 里怎么看 load average 和 wa 到底高不高
系统变慢但 top 显示 CPU 使用率（%us/%sy）并不高，往往是因为资源竞争没体现在“占用率”上，而是卡在排队或等待环节。关键看两处：load average 和 wa。
-
load average三个数（1/5/15 分钟）要和 CPU 核心数比：用nproc查核数，若load average/ 核数 > 0.7，说明有任务在排队，不一定是 CPU 满，可能是 I/O 或锁竞争堵住了 -
%Cpu(s)行里的wa（wait I/O）持续 >20%，基本可断定是磁盘或网络 I/O 在拖慢指令执行——比如ls卡住、git status延迟、脚本中read调用变慢，都可能源于此 - 别只信
%us数值低就放松：一个进程可能只占 5% CPU，但它频繁发起小文件读写，引发大量上下文切换和 I/O 等待，vmstat 1 5中的cs（context switch）和bi/bo（块设备读写）会明显升高
vmstat 输出里 r 和 b 列说明什么
vmstat -n 2 3 的第一行是平均值，后两行才是实时采样。重点盯 procs 下的 r 和 b：
-
r是“就绪态”进程数：正在 CPU 队列里等着执行的进程。单核机器r > 2就算压力大；4 核机器长期r > 8，说明调度队列已堆积，指令执行必然延迟 -
b是“不可中断睡眠态”进程数：通常卡在 I/O（如磁盘读、NFS 等待、锁争用）。只要b > 0且持续存在，就表示有进程被阻塞，不是 CPU 不够，而是它等的东西没响应 - 如果
r高 +wa低，可能是 CPU 密集型竞争（比如多线程抢锁）；b高 +wa高，则大概率是磁盘慢或存储故障（如坏扇区、RAID 降级）
iostat -x 1 看哪几列能定位指令变慢根源
运行 iostat -x 1（需安装 sysstat），每秒刷新一次，重点关注这几列：
-
%util：设备忙时百分比。接近 100% 表示磁盘带宽跑满，cp、find、tar这类指令会明显变慢；但要注意 SSD 可能%util不高却await很高，说明请求排队深 -
await：I/O 平均等待毫秒数。>50ms 是警戒线，>100ms 基本确认 I/O 延迟严重；比如journalctl -f卡顿、数据库INSERT变慢，常对应此值飙升 -
avgqu-sz：平均队列长度。>1 表示有请求在排队；>4 且await同步上升，说明底层设备响应不过来 - 对比
r/s和w/s：如果指令本身不涉及大量读写（如单纯解析 JSON 的jq），但这两列数值异常高，说明有其他进程在后台刷盘（如日志轮转、备份脚本），导致你的指令被挤占 I/O 资源
pidstat -d 1 能看出哪个命令在拖慢整个 shell
当你发现某个终端里所有命令都变慢（哪怕只是 echo $PATH 都延迟），用 pidstat -d 1 可以按进程维度抓 I/O 消耗：
- 它显示每个进程每秒的读写字节数（
kB_rd/s/kB_wr/s），比iotop更轻量，不依赖 root 权限 - 特别注意那些看似“安静”但持续写入的小进程：比如
rsyslogd正在刷磁盘、updatedb在扫描文件、或者某个 Python 脚本在反复open()小文件——它们不会吃 CPU，但会让stat()、read()系统调用变慢 - 配合
strace -p PID -e trace=io可进一步确认：如果看到大量read返回EAGAIN或长时间无返回，说明 I/O 调度层已拥塞
%us 升高，但会让 time your-command 的 real 时间远大于 user+sys。查的时候别只盯着“用了多少”，得看“等了多久”。
