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 补位。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

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 四组数据才能看清全貌。