iostat无法测存储极限吞吐，需用dd施压并配合iostat -x实时监控；dd测写速关键参数为if=/dev/zero、of=testfile、bs=1m、count=2048、oflag=direct，以绕过缓存、逼近设备峰值能力。

直接用 iostat 无法测出存储设备的极限吞吐能力——它只反映当前实际负载下的性能表现，不是压力测试工具。要测极限，得靠 dd 配合 iostat -x 实时监控，形成“施压 + 观察”的闭环。

---

为什么不能单靠 iostat 测极限？

• iostat -x 1 显示的是已有负载的真实吞吐（rMB/s、wMB/s）和延迟（await），属于被动观测；
• 它不主动发 IO，也不控制并发、块大小或缓存策略；
• 即使 %util 到 100%，也可能是应用层 IO 模式低效（比如大量 4K 同步写），而非设备跑满。

所以，正确做法是：用 dd 施加可控压力，用 iostat -x 实时验证是否逼近物理极限。

---

用 dd 测极限吞吐的实操要点

目标是绕过干扰、逼近设备原始能力，关键在参数选择：

• 顺序写测试（推荐起点）

  dd if=/dev/zero of=testfile bs=1M count=2048 oflag=direct

  • bs=1M：大块连续写，避免小 IO 队列拥塞干扰；
  • oflag=direct：跳过 page cache，但允许 SSD 内部 DRAM 缓存暂存 → 测的是「带设备缓存的峰值吞吐」；
  • count=2048（即 2GB）：足够长，避开初始缓存填充抖动。

• 同步写测试（贴近数据库 WAL 场景）

  dd if=/dev/zero of=testfile bs=64K count=16384 oflag=direct,fsync

  • bs=64K + fsync：模拟频繁刷盘，测的是「延迟敏感型吞吐」，数值会明显低于 direct 模式。

• 测完记得清理缓存（避免影响下一轮）

  echo 3 | sudo tee /proc/sys/vm/drop_caches

⚠️ 注意：别在系统盘或生产数据盘上直接跑；建议用空闲裸分区或临时逻辑卷。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

---

边测边看：用 iostat -x 实时盯住关键指标

在 dd 运行的同时，新开终端执行：

iostat -x 1

重点关注三组联动值：

• rMB/s + wMB/s：是否接近设备标称带宽？

  • SATA SSD：≈ 500 MB/s
  • NVMe Gen4 x4：≈ 3000 MB/s（3 GB/s）
  • PCIe 5.0 x4：≈ 6000–8000 MB/s

• await：若写入时持续 > 1ms（NVMe）或 > 5ms（SATA SSD），说明已触达响应瓶颈，不是带宽不够，而是延迟上不去；

• avgqu-sz：

  • NVMe 上长期 > 8，说明队列深度压满；
  • SSD 上 > 4，就值得警惕；
  • 若 avgqu-sz 很高但 rMB/s 很低 → 不是设备慢，是块太小或同步太勤。

---

补充验证：排除干扰项

• 查调度器是否匹配设备类型：

  cat /sys/block/nvme0n1/queue/scheduler  # NVMe 应为 none 或 kyber

• 确认没有限速配置（如 cgroups、blkio.weight、udev 规则）；
• 检查 RAID 卡缓存是否启用（如 LSI MegaRAID 的 WB 模式）；
• 对虚拟机环境，确认 virtio-blk 的 num_queues 和 guest kernel 的多队列支持已开启。

---

不复杂但容易忽略。