存储 Benchmark 预热冷缓存和热缓存要分开报告一、缓存状态会改变跑分结论存储 Benchmark 最容易被缓存影响。第一次读数据走磁盘第二次读可能走页缓存、数据库缓存或引擎缓存。若不区分冷缓存和热缓存跑分结论会非常混乱。冷缓存代表系统从底层存储读取的能力热缓存代表缓存命中后的能力。两者都重要但不能混在一个数字里。没有预热说明的 Benchmark参考价值很低。二、缓存层次不止一层flowchart TD A[查询请求] -- B[数据库缓存] B -- C[操作系统页缓存] C -- D[磁盘或对象存储] B -- E[结果返回]数据库引擎可能有自己的缓存操作系统有页缓存存储设备也可能有控制器缓存。一次查询快不一定说明磁盘快可能只是缓存命中。预热阶段要明确预热了什么。是预热索引、数据页、字典、元数据还是完整查询结果。不同预热方式代表不同场景。三、报告要拆分冷启动和热状态benchmark: cold_p95_ms: 820 warm_p95_ms: 96 warmup_rounds: 5 dataset_size_gb: 500报告里至少要写数据集大小、内存大小、预热轮数、是否清缓存、冷态和热态指标。数据集小于内存时Benchmark 很容易变成内存测试。# 生产环境不要随便执行清缓存命令 echo 3 /proc/sys/vm/drop_caches清缓存只能在隔离测试环境使用。生产机器上清缓存会影响真实业务不应为了跑分随意操作。四、预热也要匹配业务如果业务大多数查询命中热数据热缓存指标更接近用户体验。如果业务经常扫描冷数据冷缓存指标更重要。Benchmark 要先定义场景再选择指标。还要报告波动。存储系统受后台 compaction、刷盘、检查点、合并任务影响单次跑分不够。多轮运行、记录分位数和标准差才更可靠。预热轮数也不能随意。预热太少缓存没有稳定预热太多可能把不该热的数据也全部推入缓存。报告应说明预热轮数如何确定并给出预热过程中指标是否收敛。写入 Benchmark 同样受缓存影响。操作系统缓冲、数据库 WAL、批量提交和后台刷盘都会让短时间写入看起来很快。写入测试要观察落盘、fsync、后台合并和延迟尾部而不是只看瞬时吞吐。数据集大小必须大于关键缓存容量才能测试真实存储路径。如果数据集完全放进内存结论应明确写成内存热数据性能不要包装成磁盘性能。最后Benchmark 应提供复现实验脚本。包括建表、导数、预热、执行、清理和统计命令。没有脚本跑分很难被他人验证。还要隔离后台任务。压缩、合并、备份、检查点、自动统计信息更新都会影响存储跑分。Benchmark 期间应记录这些任务是否发生而不是默认环境安静。并发模型也要写清楚。单线程顺序读、固定并发点查、混合读写、批量扫描代表完全不同场景。只给一个吞吐数字没有请求模型无法指导选型。最后报告要包含失败和异常值。某几轮延迟异常高不能直接删掉。要说明是否由后台任务、缓存抖动或系统噪声导致。异常值往往比平均值更接近生产风险。Benchmark 还要记录硬件和内核参数。文件系统、调度器、预读策略、磁盘队列深度都会影响结果。没有这些信息别人很难复现实验。如果测试对象是分布式存储还要记录副本数、网络拓扑、数据均衡状态和故障注入情况。单节点热缓存跑分不能代表集群真实表现。最后跑分结论要服务决策。它应回答能否上线、瓶颈在哪里、下一步优化什么而不是只给一张漂亮的吞吐图。五、总结存储 Benchmark 必须区分冷缓存和热缓存说明数据集大小、内存大小、预热方式和清缓存策略。缓存状态不透明跑分就容易自欺。冷态和热态分开报告性能结论才站得住。