存储 Benchmark 的 IO 隔离别让缓存替磁盘交作业一、Benchmark 最容易测到自己想看的结果存储性能 Benchmark 看似直接跑一组读写请求记录吞吐和延迟。但如果不控制缓存、数据规模、并发模型、预热时间和后台任务很容易测到一个漂亮但无意义的结果。最常见的错误是数据集小于内存最后测到的是页缓存或 block cache而不是磁盘能力。Benchmark 的目标不是证明系统快而是回答在特定负载和资源约束下能稳定承受多少压力。没有隔离变量的跑分只能当演示材料不能指导容量规划。存储系统尤其如此因为缓存和后台整理会掩盖真实成本。二、测试链路缓存层会改变观测结果flowchart TD A[压测客户端] -- B[数据库进程] B -- C[Buffer Pool 或 Block Cache] C -- D[OS Page Cache] D -- E[磁盘设备] B -- F[后台任务] F -- E如果数据全在缓存里读延迟会非常好看如果压测刚开始还没触发 compaction、checkpoint 或刷脏页写吞吐也可能虚高。因此 Benchmark 必须区分冷读、热读、稳定写入和混合负载。不同阶段应该单独报告不要混成一个平均值。数据规模要超过缓存容量。至少要明确数据集大小、内存大小、缓存配置和命中率。若测试目标就是缓存性能可以说明若目标是存储系统整体能力必须让工作集覆盖真实数据分布。三、压测配置把变量写清楚下面是一份简化的 Benchmark 配置模板。报告里至少应出现这些字段。benchmark: dataset_size: 2TB memory: 256GB workload: read_ratio: 0.7 write_ratio: 0.3 key_distribution: zipfian duration: warmup: 30m measure: 2h metrics: - qps - p50_latency - p95_latency - p99_latency - disk_iops - cache_hit_rate只报告 QPS 不够必须报告尾延迟。存储系统里 P99 比平均值更诚实。还要记录磁盘 IOPS、带宽、CPU、内存、缓存命中率、后台任务和错误率。否则看见延迟尖刺时无法判断是磁盘满、CPU 满还是后台任务抢资源。负载分布也要真实。均匀随机和 Zipfian 热点分布差异很大。线上业务往往存在热点 key、时间窗口和批量写入。压测如果只用均匀分布结论会偏乐观。四、执行纪律预热、稳态和复跑Benchmark 要有预热阶段让缓存、JIT、连接池和后台任务进入相对稳定状态。预热数据不能混进正式结果。正式测量时间也不能太短至少要覆盖后台任务周期。对于 LSM 系统短时间压测尤其容易忽略 compaction 债务。每组实验应复跑多次并记录方差。存储性能受硬件状态、云盘限流、邻居噪声和后台任务影响明显。只跑一次就下结论基本是在赌运气。报告中写清环境和方差比单个漂亮数字更有价值。最后要隔离客户端瓶颈。压测机 CPU、网络和连接数不足会让数据库看起来很轻松。客户端和服务端都要监控必要时使用多台压测机。Benchmark 测的是系统不是压测脚本的极限。五、总结存储 Benchmark 必须隔离缓存、数据规模、负载分布、后台任务和客户端瓶颈。报告 QPS 之前先说明工作集是否超过内存、预热多久、尾延迟如何、磁盘是否真的被打到。别让缓存替磁盘交作业跑分才有工程意义。