PostgreSQL性能问题

Question

我可以在postgresql日志中看到，某些简单的查询（没有连接和仅使用使用索引的匹配条件）需要1到3秒才能执行。我记录执行时间超过一秒的查询，因此有类似的查询在一秒钟内执行但没有报告。

当我使用EXPLAIN ANALYZE尝试相同的查询时，需要几毫秒。

该表包含大约800万条记录，并被写入并广泛查询。 我已经启用了自动真空，甚至最近（几个小时前）在那张桌子上运行了VACUUM ANALYZE。

示例查询日志条目： 12月30日10:14:57 db01 postgres [7400]：[20-1]日志：持续时间：3857.322 ms语句：SELECT * FROM“respond”WHERE（“respond”.contest_id = 17469）AND（user_id不是 12月30日10:14:57 db01 postgres [7400]：[20-2] null）ORDER BY updated_on desc LIMIT 5

对contest_id和user_id编制索引。 updated_on未编入索引。如果我将其编入索引，则查询计划程序会忽略contest_id索引，而是使用updated_on，这会进一步降低查询速度。没有LIMIT的上述查询的最大条目不会超过1000。

非常感谢任何帮助。

Answer 1

此处的一些细节可能会有所帮助，具体取决于您是否可以提供。最有用的是EXPLAIN ANALYZE的实际输出，以便我们可以看到它在完成查询时的作用。被查询的表的定义也可能与索引一起证明是有用的。越多的信息越多越好。我现在只能猜测发生了什么，这里有几个盲目的刺：

• 这个数据库同时发生了很多其他的SELECT，并且数据和/或结果会定期从某个缓存中到期。
• 还有一些其他内容会定期锁定此表达3-4秒，然后再次释放它，在此期间此查询被卡住
• 此表格被广泛写入所有，表格统计数据最终几乎从未反映现实，因此查询分析器会决定是否使用索引来执行查询。

其他人可能有其他想法，但是。有关正在发生的事情的更多信息可能会有用。

Answer 2

这似乎是由于交换而发生的。

Answer 3

pgsql-performance是一个很好的邮件列表，可以提出这类问题。

这似乎你有两个问题：

1）您希望能够索引updated_on，但如果这样做，PostgreSQL会选择错误的计划。

我的第一个猜测是，PostgreSQL高估了与谓词“(responses.contest_id = 17469) AND (user_id is not null)”匹配的元组数。如果postgres首先使用该谓词，则必须稍后对值进行排序以实现ORDER BY。你说它匹配1000元组;如果postgresql认为它匹配100000，也许它认为使用updated_on索引按顺序扫描会更便宜。另一个因素可能是您的配置：如果work_mem设置为低，则可能会认为排序比它更昂贵。

你真的需要显示一个慢查询的EXPLAIN ANALYZE输出，以便我们可以看到为什么它可能在updated_on上选择索引扫描。

2）即使它没有编入索引，有时需要一段时间才能执行，但你不知道为什么，因为如果你手动运行它就可以正常工作。

使用auto_explain contrib模块，新模块8.4。它允许您记录花费时间过长的查询的EXPLAIN ANALYZE输出。只需记录查询就可以解决您现在遇到的问题：每次运行查询都很快。

Answer 4

如果完全相同的查询在explain analyze中占用毫秒，在日志中占用3秒（即我假设它恰好需要3秒，而不是每次调用都花费那么长时间） - 而不是它绝对意味着它是锁定问题

Answer 5

• 锁定
• 交换
• cron job中的CLUSTER / VACUUM
• 饱和网络
• 饱和IO

检查iostat，vmstat，iptraf ......