企业官网建设流程全解析

存储 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 之前，先说明工作集是否超过内存、预热多久、尾延迟如何、磁盘是否真的被打到。别让缓存替磁盘交作业，跑分才有工程意义。