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