我正在使用在 Debian Linux 上运行的 Postgresql 9.1 执行一些基准测试任务。我想对共享公共部分的查询工作负载进行基准测试。在运行每个查询之前，我重新启动数据库并执行以下命令：
echo 3 > /proc/sys/vm/drop_caches
旨在删除共享内存和操作系统缓存。但是，我注意到，如果我以不同的顺序运行相同的查询工作负载，我会得到不同的查询响应时间。我怀疑查询优化器以某种方式“记住”了如何有效地执行常见的查询部分，或者重用了一些以前缓存的结果。
您对如何解决此问题有任何想法吗？无论查询顺序如何，我都希望获得大致相同的响应时间。请注意，我正在解析 EXPLAIN 输出以提取实际运行时间。
【问题讨论】：
标签： query-optimization benchmarking postgresql-9.1
首先想到的是 autovacuum（PostgreSQL 中的后台维护任务：http://www.postgresql.org/docs/current/interactive/routine-vacuuming.html#AUTOVACUUM）可能正在做一些工作，以难以预测的方式重新填充缓存。您可以禁用它，但请注意，这可能会导致臃肿、错误的统计数据导致错误的计划选择，并将额外的工作推到前端进程上——因此通常不建议这样做。解决此问题的另一种方法是在加载数据后运行 VACUUM FREEZE ANALYZE，将所有内容置于维护良好的状态，停止 PostgreSQL，刷新操作系统缓存，然后启动并执行基准测试。
另一个可能的问题来源可能是检查点；您应该确保已将 checkpoint_segments 配置得足够高以避免强制频繁的检查点，并且您应该根据检查点在基准测试期间发生的时间来考虑 checkpoint_timeout 设置。
也有可能是 RAID 控制器卡或硬盘驱动器的缓存足够重要——我不知道刷新操作系统缓存是否会清除这些，但我对此表示怀疑。
一般来说，请记住 PostgreSQL 附带的设置旨在让数据库在小型笔记本电脑上启动和运行——最佳性能通常需要进行一些调整，因此除非您的基准测试正在测试不同配置设置的效果，否则您可能想要在基准测试之前检查整体配置。
【讨论】：