共计 1534 个字符,预计需要花费 4 分钟才能阅读完成。
背景痛点
开发者在进行磁盘性能测试时常常遇到几个典型问题:

- 工具选择困难 :市面上工具众多(fio、dd、iometer 等),各工具测试维度不同,难以直接比较
- 参数配置复杂 :block size、queue depth 等专业参数不理解如何设置
- 测试结果不稳定 :未考虑系统缓存、后台进程干扰等因素导致数据波动
- 结果解读门槛高 :IOPS、吞吐量、延迟等指标的实际业务含义不明确
技术对比
| 工具 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| atto | 轻量级 (仅 300KB)、零配置依赖 | 测试维度单一 (仅顺序读写) | 快速验证硬件基础性能 |
| fio | 支持丰富 IO 模式 (随机 / 顺序 / 混合) | 配置复杂、学习曲线陡峭 | 专业级存储性能分析 |
| dd | 系统内置、简单直接 | 仅测试连续读写、无并发控制 | 极简场景下的基础测试 |
核心实现原理
atto 通过以下机制实现精准测量:
- 直接 IO 绕过缓存 :使用 O_DIRECT 标志避免文件系统缓存干扰
- 双缓冲机制 :
- 前台缓冲:接收用户数据
- 后台缓冲:异步执行实际磁盘写入
- 时间窗口统计 :动态计算 1 秒内的 IO 完成量
关键参数解析:
- -s 128k:设置每次 IO 操作的块大小(常见 4k~1M)
- -l 32:设定队列深度(SSD 建议≥32)
- -t 60:测试持续时间(秒)
完整测试示例
# 测试 1GB 文件,块大小 128k,队列深度 32,持续 60 秒
./atto -f /mnt/testfile -s 128k -l 32 -t 60
# 预期输出示例:# -------------------------------------------------
# Atto v3.0 Disk Benchmark
# File: /mnt/testfile
# Block Size: 131072 bytes
# Queue Depth: 32
# Runtime: 60 seconds
# -------------------------------------------------
# Write: 985 MB/s (7680 IOPS)
# Read: 1052 MB/s (8214 IOPS)
# Latency (avg): 3.89ms
性能影响因素
硬件层面
- SSD/NVMe:关注 4K 随机读写 IOPS
- HDD:重点看顺序吞吐量
系统配置
- CPU 亲和性 (推荐):
taskset -c 0 ./atto [参数] # 绑定到特定 CPU 核心 - 关闭节能模式 :
cpupower frequency-set -g performance - 文件系统选择 :
- XFS:大文件性能最佳
- EXT4:通用场景平衡
五大常见错误
- 未清除缓存 :
sync; echo 3 > /proc/sys/vm/drop_caches - 测试时间过短 :建议≥30 秒避免突发性能干扰
- 队列深度不合理 :
- HDD:保持 1 -2
- SSD/NVMe:建议 32-256
- 误读 MB/ s 数值 :需结合块大小换算实际 IOPS
IOPS = (MB/s × 1024) / block_size_kb - 忽视延迟指标 :当 IOPS>10 万时需特别关注
生产环境建议
- 基准测试流程 :
- 空盘→50% 占用→满盘 三阶段测试
- 不同 block size(4k/64k/1M) 组合测试
- 监控干扰项 :
iostat -xmt 1 # 实时监控磁盘利用率 - 结果记录模板 :
| 测试场景 | 块大小 | QD | 写入 (MB/s) | 读取 (MB/s) | 延迟 (ms) | |---------------|--------|----|------------|------------|----------| | 空盘 -4k 随机 | 4k | 32 | 85 | 92 | 1.2 |
延伸思考
- 当 atto 测试结果与 fio 差异较大时,可能是什么原因?
- 如何设计测试方案来模拟数据库的真实 IO 模式?
- 在云环境(如 AWS EBS)中测试需要特别注意哪些参数?
通过本文的实操指南,开发者可以快速掌握 atto 的核心用法。建议在实际测试中保存历史数据建立性能基线,这对后续容量规划、故障排查都有重要价值。
正文完
