3

我正在使用在 Debian Linux 上运行的 Postgresql 9.1 执行一些基准测试任务。我想对共享公共部分的查询工作负载进行基准测试。在运行每个查询之前,我重新启动数据库并执行以下命令:

回声 3 > /proc/sys/vm/drop_caches

旨在删除共享内存和操作系统缓存。但是,我注意到,如果我以不同的顺序运行相同的查询工作负载,我会得到不同的查询响应时间。我怀疑查询优化器以某种方式“记住”了如何有效地执行公共查询部分或重用一些以前缓存的结果。

您对如何解决此问题有任何想法吗?无论查询顺序如何,我都希望获得大致相同的响应时间。请注意,我正在解析 EXPLAIN 输出以提取实际运行时间。

4

1 回答 1

2

首先想到的是 autovacuum(PostgreSQL 中的后台维护任务:http ://www.postgresql.org/docs/current/interactive/routine-vacuuming.html#AUTOVACUUM )可能正在做一些重新- 以难以预测的方式填充缓存。您可以禁用它,但请注意,这可能会导致臃肿、错误的统计数据导致错误的计划选择,并将额外的工作推到前端进程上——因此通常不建议这样做。解决这个问题的另一种方法是在加载数据后运行 VACUUM FREEZE ANALYZE,将所有内容置于维护良好的状态,停止 PostgreSQL,刷新操作系统缓存,然后启动并执行基准测试。

另一个可能的问题来源可能是检查点。您应该确保已将 checkpoint_segments 配置得足够高以避免强制频繁检查点,并且您应该根据检查点在基准测试期间发生的时间来考虑 checkpoint_timeout 设置。

RAID 控制器卡或硬盘驱动器的缓存也可能足够重要——我不知道刷新操作系统缓存是否会清除这些,但我对此表示怀疑。

一般来说,请记住 PostgreSQL 附带的设置旨在让数据库在小型笔记本电脑上启动和运行——最佳性能通常需要一些调整,因此除非您的基准测试正在测试不同配置设置的效果,否则您可能需要查看基准测试前的整体配置。

于 2012-04-03T14:36:36.247 回答