存储性能测试方法论：从 fio 到业务场景的 Benchmark 设计
一、Benchmark 的常见误区：跑分不等于性能
存储性能测试最常见的误区是直接用 fio 跑出最高 IOPS 和最低延迟，然后声称"存储性能达标"。但 fio 的顺序读写测试与数据库的随机读写模式差异巨大——数据库的写入是先写 WAL（顺序）再写数据文件（随机），读取是按索引跳转（随机）加范围扫描（顺序）。fio 的纯随机测试无法反映真实业务负载。
更深层的问题是，存储性能不是单一指标。IOPS、吞吐量、延迟三个指标相互制约——提高并发度可以提升 IOPS 但延迟也会增加。业务场景对三个指标的容忍度不同：OLTP 关注 P99 延迟，OLAP 关注吞吐量，日志系统关注写入 IOPS。
二、存储性能指标体系：IOPS、吞吐量与延迟的三角关系
存储性能的三个核心指标：IOPS（每秒 IO 操作数）、吞吐量（MB/s）、延迟（ms）。三者之间存在制约关系——在固定硬件下，提高 IOPS 通常会增加延迟，提高吞吐量需要增大 IO 尺寸。
flowchart TB A[存储性能三角] --> B[IOPS<br/>每秒 IO 操作数] A --> C[吞吐量<br/>MB/s] A --> D[延迟<br/>ms] B --> E[制约关系] C --> E D --> E E --> F[高 IOPS → 高并发 → 延迟上升] E --> G[高吞吐 → 大 IO 尺寸 → IOPS 下降] E --> H[低延迟 → 低并发 → IOPS 受限] subgraph 业务场景映射 I[OLTP: 关注 P99 延迟<br/>随机读写 4KB-16KB] J[OLAP: 关注吞吐量<br/>顺序读写 64KB-1MB] K[日志: 关注写入 IOPS<br/>顺序写入 4KB-16KB] end I --> D J --> C K --> B关键认知：存储性能测试必须模拟业务负载的 IO 模式（随机/顺序、读写比、IO 尺寸），而非追求单一指标的最优值。
三、生产级代码实现：fio 测试与业务场景 Benchmark
3.1 fio 基础性能测试
# 随机读测试（模拟 OLTP 读负载） # 为什么用 4KB 随机读：数据库的索引查找是 # 4KB-16KB 的随机 IO，这是 OLTP 场景的 # 典型 IO 模式 fio --name=rand_read \ --ioengine=libaio \ --iodepth=32 \ --rw=randread \ --bs=4k \ --direct=1 \ --size=10G \ --numjobs=4 \ --runtime=60 \ --time_based \ --group_reporting \ --output=rand_read.json # 随机写测试（模拟 WAL 写入） # 为什么用 libaio 而非 sync：libaio 是 Linux # 原生异步 IO 引擎，支持 IO 深度 > 1， # 能充分利用存储设备的并行能力； # sync 引擎是同步的，iodepth 参数无效 fio --name=rand_write \ --ioengine=libaio \ --iodepth=32 \ --rw=randwrite \ --bs=4k \ --direct=1 \ --size=10G \ --numjobs=4 \ --runtime=60 \ --time_based \ --group_reporting # 混合读写测试（模拟 OLTP 负载） # 为什么 70/30 读写比：OLTP 场景的读写比 # 通常在 70:30 到 80:20 之间 fio --name=mixed_rw \ --ioengine=libaio \ --iodepth=32 \ --rw=randrw \ --rwmixread=70 \ --bs=4k \ --direct=1 \ --size=10G \ --numjobs=4 \ --runtime=60 \ --time_based \ --group_reporting # 顺序写测试（模拟 WAL 和日志写入） fio --name=seq_write \ --ioengine=libaio \ --iodepth=16 \ --rw=write \ --bs=16k \ --direct=1 \ --size=10G \ --numjobs=2 \ --runtime=60 \ --time_based \ --group_reporting3.2 数据库场景 Benchmark
import time import statistics from dataclasses import dataclass, field from typing import List @dataclass class BenchmarkResult: """Benchmark 结果""" scenario: str total_operations: int duration_seconds: float iops: float throughput_mbps: float latency_p50_ms: float latency_p99_ms: float latency_max_ms: float class DatabaseBenchmark: """数据库场景 Benchmark""" def __init__(self, db_connection): self.db = db_connection def oltp_point_select(self, iterations=100000) -> BenchmarkResult: """OLTP 点查 Benchmark""" latencies = [] for _ in range(iterations): start = time.perf_counter() cursor = self.db.cursor() cursor.execute( "SELECT * FROM orders WHERE id = %s", (self._random_id(),)) cursor.fetchone() elapsed = (time.perf_counter() - start) * 1000 latencies.append(elapsed) return self._compute_result("oltp_point_select", iterations, latencies) def oltp_range_scan(self, iterations=10000) -> BenchmarkResult: """OLTP 范围扫描 Benchmark""" latencies = [] for _ in range(iterations): start = time.perf_counter() cursor = self.db.cursor() cursor.execute( "SELECT * FROM orders " "WHERE created_at BETWEEN %s AND %s " "LIMIT 100", (self._random_date(), self._random_date())) cursor.fetchall() elapsed = (time.perf_counter() - start) * 1000 latencies.append(elapsed) return self._compute_result("oltp_range_scan", iterations, latencies) def oltp_write(self, iterations=50000) -> BenchmarkResult: """OLTP 写入 Benchmark""" latencies = [] for _ in range(iterations): start = time.perf_counter() cursor = self.db.cursor() cursor.execute( "INSERT INTO orders " "(id, user_id, amount, created_at) " "VALUES (%s, %s, %s, NOW())", (self._gen_id(), self._random_id(), self._random_amount())) self.db.commit() elapsed = (time.perf_counter() - start) * 1000 latencies.append(elapsed) return self._compute_result("oltp_write", iterations, latencies) def _compute_result(self, scenario, total, latencies): """计算 Benchmark 结果""" latencies.sort() duration = sum(latencies) / 1000 # ms → s iops = total / duration if duration > 0 else 0 # 估算吞吐量（假设平均行大小 200 字节） avg_row_size = 200 throughput = (total * avg_row_size / 1024 / 1024) / duration return BenchmarkResult( scenario=scenario, total_operations=total, duration_seconds=round(duration, 2), iops=round(iops, 2), throughput_mbps=round(throughput, 2), latency_p50_ms=round( latencies[len(latencies) // 2], 2), latency_p99_ms=round( latencies[int(len(latencies) * 0.99)], 2), latency_max_ms=round(latencies[-1], 2), )3.3 结果对比与报告
class BenchmarkReporter: """Benchmark 报告生成器""" def compare(self, results: List[BenchmarkResult]) -> str: """生成对比报告""" report = "# 存储性能 Benchmark 报告\n\n" report += "| 场景 | IOPS | 吞吐量(MB/s) | P50(ms) | P99(ms) | 最大(ms) |\n" report += "|------|------|-------------|---------|---------|----------|\n" for r in results: report += (f"| {r.scenario} | {r.iops} | " f"{r.throughput_mbps} | " f"{r.latency_p50_ms} | " f"{r.latency_p99_ms} | " f"{r.latency_max_ms} |\n") # 性能评估 # 为什么关注 P99 而非均值：P99 反映 # 尾部延迟，是用户体验的瓶颈； # 均值被大量正常请求稀释， # 无法反映最差情况 report += "\n## 性能评估\n" for r in results: if r.latency_p99_ms > 50: report += f"- ⚠️ {r.scenario}: P99 延迟 {r.latency_p99_ms}ms 超过 50ms 阈值\n" elif r.latency_p99_ms > 20: report += f"- ⚡ {r.scenario}: P99 延迟 {r.latency_p99_ms}ms，需要关注\n" else: report += f"- ✅ {r.scenario}: P99 延迟 {r.latency_p99_ms}ms，性能良好\n" return report四、存储 Benchmark 的架构权衡：测试保真度、成本与可重复性
测试保真度 vs 测试成本：fio 测试成本低但保真度低，数据库 Benchmark 保真度高但需要准备测试数据和环境。建议先用 fio 确认存储硬件的基本性能，再用数据库 Benchmark 验证业务场景性能。
测试数据的代表性：Benchmark 的测试数据必须与生产数据的分布一致——索引选择性、数据倾斜、行大小。用随机数据做 Benchmark 可能得出过于乐观的结果。
缓存的影响：数据库的 Buffer Pool 缓存会显著影响读性能。冷启动（缓存为空）和热启动（缓存已预热）的延迟可能差 10 倍。建议分别测试冷启动和热启动性能，冷启动反映系统重启后的恢复时间。
可重复性：存储性能受系统负载、缓存状态和 CPU 频率影响，同一测试可能得到不同结果。建议每次测试前清空缓存（drop_caches），固定 CPU 频率（cpupower frequency-set -g performance），并在无其他负载的环境下测试。
五、总结
存储性能测试的核心是模拟业务负载的 IO 模式，而非追求 fio 跑分。OLTP 场景关注 P99 延迟和随机 IOPS，OLAP 场景关注吞吐量和顺序读写，日志场景关注写入 IOPS。落地时建议先用 fio 验证硬件基线，再用数据库 Benchmark 验证业务性能。测试结果必须包含 P99 延迟，均值和最大值都不足以反映用户体验。
