top中load average高且%wa>20%时，可判定为I/O瓶颈而非CPU算力不足，需联动iostat、iotop和vmstat交叉验证磁盘队列、进程I/O及内存换页情况。
top 里看 load average 和 %wa 是第一反应
系统变慢时，top 不是用来“找进程”的第一步，而是快速判断瓶颈类型的关键入口。别急着按 P 排序，先盯住两行：load average 和 %Cpu(s) 下的 wa（wait I/O）。
如果 load average 远高于 CPU 核心数（比如 8 核机器显示 12.45, 10.21, 9.87），同时 wa 持续 >20%，基本可断定不是 CPU 算力不够，而是资源在排队等磁盘或网络响应——本质是资源竞争，不是单个进程吃满 CPU。
-
load average高 +us高 → 应用层计算密集，查具体进程 -
load average高 +wa高 → I/O 竞争，下一步必须看iostat和iotop -
load average正常但操作明显卡顿 → 可能是单点阻塞（如锁、DNS、数据库连接池耗尽），不能只看全局指标
iostat -x 1 看清磁盘是否真忙
iostat -x 1 输出里，%util 和 await 必须一起看，单独看 %util 容易误判。SSD 上 %util 到 95% 可能仍健康，但若 await 超过 50ms，说明请求已在队列里积压；HDD 上 await > 100ms 就已严重异常。
重点字段含义：
-
avgqu-sz：平均队列长度，>4 表示 I/O 请求开始堆积 -
r_await/w_await：分别看读/写平均等待时间，差异大说明负载不均衡（比如日志写爆了但读正常） -
svctm已废弃，Linux 内核 2.6.34+ 后不再更新，忽略它
注意：iostat 默认统计的是设备层，看不出哪个进程在刷盘——得靠 iotop 补位。
iotop 找出真实“抢盘”进程
iotop 是唯一能实时看到“谁在读、谁在写、每秒多少 MB”的工具。运行前确认已安装：sudo apt install iotop 或 sudo yum install iotop。
关键操作：
- 启动后按
o只显示有 I/O 的进程（避免被 idle 进程干扰） - 按
P按实际 I/O 速率排序，不是按 %IO - 注意区分
DISK READ和DISK WRITE列，有些服务（如 Elasticsearch）写多读少，另一些（如 CDN 缓存）读多写少 - 若看到
java或mysqld占比极高，别急着 kill，先检查其配置：MySQL 的innodb_io_capacity是否远低于磁盘能力？Java 应用是否在频繁刷日志到小文件？
vmstat 1 揭露隐藏的内存换页压力
有时 top 里内存看着够，free -h 的 available 也还剩 2GB，但系统就是卡——这时候 vmstat 1 的 si（swap-in）和 so（swap-out）才是真相。
只要 si 或 so 持续 >0，哪怕只有 10 KB/s，也代表物理内存已不足，内核正在把进程页换入换出。这种抖动比 CPU 满载更伤性能，因为涉及磁盘随机访问。
- 配合
smem -s rss查真实 RSS 占用，比top的VIRT更准 - 查
dmesg | grep -i "killed process"，确认 OOM killer 是否近期干掉过进程 - 注意：
buff/cache高是好事，Linux 会自动回收；真正危险的是available持续低于 5% 且si/so抬头
资源竞争从来不是孤立发生的：高 I/O 往往触发换页，换页又加剧 I/O，最终所有指标互相拉扯。盯着单一命令输出容易漏掉链条，必须交叉验证 top、iostat、iotop、vmstat 四组数据才能看清全貌。
