wa高但%util不高不一定是i/o瓶颈，可能是文件系统锁、lvm元数据争用、nfs重试或page cache回刷导致；应优先看await和pidstat -d定位进程。
vmstat 输出里 wa 高但磁盘 %util 不高，到底是不是 I/O 瓶颈？
wa 表示 CPU 等待 I/O 完成的时间百分比，但它只反映“等待”，不反映“忙”。而 iostat -x 中的 %util 是设备忙时间占比（基于队列非空且有请求在处理的时间），两者统计逻辑不同。
常见错误现象：看到 wa > 30%，立刻断定磁盘慢；但 iostat -x 1 显示 %util await 也正常（比如
这通常说明：
- I/O 请求确实排队了，但设备本身没饱和
- 可能是存储栈上层瓶颈：如文件系统锁（ext4 journal 堵塞）、LVM thin pool 元数据争用、或 NFS 客户端重试风暴
- 也可能是大量小随机写触发了内核 page cache 回刷延迟，
wa上升但块设备没真正压满
实操建议：
- 优先看
iostat -x 1的await（平均响应时间）和r_await/w_await - 若
await显著升高（> 20ms 持续），再查设备层；若await正常但wa高，转向pidstat -d 1查哪个进程在频繁fsync或write小 buffer - 注意：
wa在多核下是全局平均值，单个 CPU 核可能已 100%wa，需配合mpstat -P ALL 1看分布
iostat -x 输出中 svctm 已被废弃，该信谁？
svctm 从 sysstat 10.0.0 开始被标记为“always 0”，文档明确说明它不再计算也不应使用。它的原始设计依赖于过时的内核计时机制，现代 I/O 调度器（如 mq-deadline、bfq）和 NVMe 多队列模型让它完全失真。
容易踩的坑：
- 旧脚本或监控模板还在取
svctm做“服务时间”判断，导致误报 - 把
svctm和await对比，得出“设备很快但响应慢”的错误结论
实操建议：
- 彻底忽略
svctm字段，所有性能判断只基于await、r_await、w_await -
await=svctm+queue wait time，现在它真实包含了排队开销，反而更贴近应用感知的延迟 - 如果需要区分设备处理时间和排队时间，用
cat /sys/block/*/stat手动算：字段 10（io_ticks）/ 字段 3（ios）≈ 平均服务时间（毫秒级，需换算），但日常分析没必要
vmstat 的 bi/bo 和 iostat 的 r/s/w/s 数值对不上，怎么校准？
bi（blocks in）和 bo（blocks out）单位是“块/秒”，默认块大小为 1024 字节（即 1 KiB），而 iostat 的 r/s、w/s 是“请求次数/秒”，不是字节数。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
关键差异：
-
vmstat统计的是底层块设备读写的总数据量（按 1KiB 块折算） -
iostat默认显示请求频次；加-k才显示 KB/s，加-m显示 MB/s - 同一时刻，
vmstat的bi值 ≈iostat -k的rkB/s，而非r/s
常见错误现象：
- 直接对比
vmstat的bi=200和iostat的r/s=50，以为 I/O 效率低 - 忽略
iostat默认输出不含单位后缀，误读数值
实操建议：
- 要比吞吐量，统一用
iostat -k 1看rkB/s和wkB/s，与vmstat的bi/bo基本一致（允许几 % 误差，因采样时机差） - 要比 I/O 密集度，用
iostat -x 1的avgrq-sz（平均请求大小 KB）反推：若r/s=100且avgrq-sz=32，则实际吞吐 ≈ 3200 KB/s，对应vmstat的bi≈3200 - 注意：XFS 日志写、ext4 journal 提交等元数据 I/O 会被
iostat计入，但vmstat的bi包含全部，所以日志密集型负载下二者偏差会略大
用 iostat 监控云盘（如 AWS EBS gp3、阿里云 ESSD）时，%util 失效怎么办？
云盘本质是网络存储，%util 的物理设备忙时间定义失效。gp3 的吞吐和 IOPS 是独立配额，ESSD 的 burst 性能受 credits 影响——这些都无法用“设备忙比例”描述。
典型表现：
-
%util长期 100%，但await仍很低（ - 或
%util只有 20%，但await突然飙到 100ms+，说明云盘限速已触发
实操建议：
- 对云盘，
%util完全丢弃，只盯三个指标：await、r/s+w/s（是否接近 provisioned IOPS）、rkB/s+wkB/s（是否接近 provisioned throughput） - AWS gp3：关注 CloudWatch 中
VolumeQueueLength，iostat 里没有对应字段，需额外采集 - 阿里云 ESSD：
await持续 > 10ms 且r/s+w/s接近规格值，基本可判定 credit 耗尽或突发限速
真实场景里，await 的基线波动比 %util 更敏感——哪怕只是 1~2ms 的持续抬升，结合 iostat -x 的 qu-sz（平均队列深度）同步增长，就是云盘开始吃紧的信号。别等它超时才反应。
