iostat -x 1 是唯一可靠方式，因其 rMB/s、wMB/s 绕过 page cache 直接反映块设备真实吞吐，r_ios、w_ios 为驱动层实际 I/O 次数；普通 iostat 的 rkB/s、wkB/s 和 r/s、w/s 受缓存、请求合并及多路径干扰严重失真。
iostat -x 1 是唯一靠谱的实时吞吐查看方式
别用 dstat、vmstat 或普通 iostat，它们显示的 rkB/s 和 wkB/s 是 VFS 层统计值，大量命中 page cache 后数值虚高，跟真实磁盘带宽完全对不上。只有 iostat -x 1 输出的 rMB/s 和 wMB/s 字段，才是绕过缓存、直接从块设备驱动上报的真实吞吐（单位 MB/s），可对标 SSD 厂商标称值。
-
iostat -xh 1：自动换算单位（K/M/G），读起来更直观，字段名仍是 MB 但数值已适配 -
iostat -xk 1：固定 KB 单位，数值精确，适合脚本解析（注意字段名仍叫rMB/s，是历史兼容） - 只看某盘？加设备路径：
iostat -xh 1 /dev/sdb - 要看所有分区（含 LVM）？用
iostat -xh 1 -p ALL
为什么 await 和 %util 必须一起看
%util 接近 100% ≠ 磁盘瓶颈，它只是设备忙时占比；await 高也不等于磁盘慢——关键看两者关系。SSD 上 %util 才 60% 就可能因队列深度不足导致 await 暴涨；而 HDD 在 %util 95% 时 IOPS 可能还不到 200。
-
%util ≈ 100%且await显著升高 → 请求在队列里排队，不是设备处理慢，而是并发或介质响应能力跟不上 -
%util低但await高 → 可能是单个请求本身慢（如小块随机读、RAID 卡降速、NVMe 控制器 flush 延迟） -
avgqu-sz> 1（SSD）或 > 2（HDD）→ 平均队列长度已积压，需检查avgrq-sz是否过小（如长期
dd 和 fio 测出来的数字为什么和 iostat -x 对不上
因为 dd 默认走 page cache，fio 默认多线程并发，而 iostat -x 统计的是内核块层实际落盘行为。三者测量维度根本不同：一个是用户态单线程模拟，一个是工具压测，一个是设备驱动真实上报。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
dd if=/dev/zero of=test bs=1M count=1024 oflag=direct：绕过 page cache，但不强制刷盘，测的是“带设备缓存”的顺序写吞吐 -
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --direct=1 --sync=1：同时绕过 cache + 强制落盘，结果才接近 WAL 写入等强一致性场景 -
iostat -x 1的wMB/s是上述测试过程中真正落到设备的数据速率，不是命令输出的“速度”，而是内核统计值
iotop 显示的 DISK WRITE 不等于 iostat 的 wMB/s
iotop -o 顶部的 Total DISK WRITE 是内核块层统计，含未落盘的 write-back 缓存；而 Actual DISK WRITE 才是真正发往磁盘的量。两者差值大，说明写缓存堆积严重——这时 iostat -x 的 wMB/s 会明显低于 iotop 显示值，且 %util 可能不高，但业务延迟已上去了。
- 验证方法：对比
iotop的Actual DISK WRITE和iostat -x的wMB/s，若持续相差 2 倍以上，说明缓存层（RAID 卡、NVMe controller、文件系统 journal）正在缓冲 - 查缓存状态：
cat /proc/sys/vm/swappiness（影响脏页回写节奏）、sysctl vm.dirty_ratio（触发同步回写的阈值） - 不要只盯着某个进程 IO 高就 kill，先确认它是“主动刷盘”还是“被动背锅”——结合
iostat -x的%util和await才能分清是进程太贪，还是磁盘太弱
真实吞吐必须排除 page cache、设备 DRAM 缓存、RAID 卡 write-back 缓存三层干扰，iostat -x 是唯一能绕过前两层的观测入口，但它不告诉你第三层是否生效——这点最容易被忽略。
