分析PostgreSQL

Question

我正在研究一个PostgreSQL支持的应用程序。

在配备4 4GB的现代Xeon上，CPU使用率始终保持在50%以上。在这50%的CPU利用率中，67%是“用户”，33%是“系统”(这是一台Linux机器)。系统根本没有等待I/O。

我想知道如何才能看到CPU时间是如何分解的。

据我所知，这些查询大多是即席SQL (没有准备好的语句)。

您认为将此用户的CPU时间转移到预准备语句可以显著减少吗？也就是说，SQL解析时间、查询规划时间等会占用这么多CPU吗？有些查询非常庞大(500-1000个字符以上)。

有没有人能确认PostgreSQL是否会自动标准化即席查询并缓存它们的查询计划，从而使它们像准备好的语句一样高效(加上SQL解析时间)？

我可能会实现一些更高级别的缓存来解决这个问题，但我很好奇是否有人认为将这个应用程序转移到预准备语句是值得的。

Answer 1

假设您经常对数据库执行VACUUM操作(这是PostgreSQL性能问题的标准根源)，我认为获得最佳性能的方法是

a)基于您所在机器的tune your installation for performance

b) analyze each query，看看是否可以进一步优化。

我真的不认为将查询转移到存储过程中会获得多少好处。

Answer 2

您可能还没有看到的一个技巧是使用"top -c“来查看您的系统。有了这个参数，您就可以看到每个活动的Postgres进程实际在做什么。

查询计划不会以任何方式缓存在数据库中的预准备语句之外。无论如何，如果您没有大量重用类似的查询，则不太可能使用预准备语句来缩短查询时间。如果这样做最终会给优化器提供更少的信息，你甚至可能会让事情变得更糟，因为它在知道要做什么的所有信息之前就准备好了。1000个字符远不是一个庞大的查询，除非你一次有数百个连接，否则在这里你的问题不太可能是查询解析或规划。这可能是锁定问题，糟糕的真空过程导致需要搜索膨胀的数据才能完成任何工作(在8.1中很容易遇到)，缓慢的约束，过多的索引，或者没有充分考虑在内存中移动对象的开销的设计。在嫌犯列表中，查询开销非常低。

如果你有数百个连接，你应该考虑使用连接池。PostgreSQL进程的创建相当繁重，而且在那个环境中它自己做得并不好。

糟糕，你运行的是一个如此老的版本，甚至8.1，你可能会看到一个bug；8.1.4充满了它们。8.1.19是最新的，甚至8.3.5已经是当前的几个有用的版本升级)。有关为什么在几乎所有情况下运行旧版本都比升级更大风险的详细信息，请参阅Versioning Policy。