分析 PostgreSQL答案

【问题标题】：Profiling PostgreSQL分析 PostgreSQL
【发布时间】：2010-10-01 02:14:24
【问题描述】：

我正在调查一个 PostgreSQL 支持的应用程序。

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

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

据我所知，查询大多是临时 SQL（没有准备好的语句）。

您认为转移到准备好的语句可以显着减少此用户 CPU 时间吗？即 SQL 解析时间、查询计划时间等是否会占用这么多 CPU？有些查询非常粗略（500-1000 个字符以上。）

谁能确认 PostgreSQL 是否自动规范化即席查询并为它们缓存查询计划，实际上使它们与准备好的语句一样高效（加上 SQL 解析时间）？

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

【问题讨论】：

你使用的是什么版本的 PostgreSQL？
它是 8.1.4，尽管该项目的一部分是将其升级到 8.3.5
您的连接建立/断开率是多少？如果在很多情况下，数据库 CPU 使用率高是由于在同时查询率非常高的环境中每个查询都有自己的短期连接。

标签： postgresql

【解决方案1】：

假设您定期VACUUMing 数据库（这是 PostgreSQL 性能问题的标准来源），我认为赢得最明智的性能的方法是

a) tune your 安装 for performance 基于您所在的机器和

b) analyze each query 并找出是否可以进一步优化。

我真的认为将查询移动到存储过程中不会有什么好处。

【讨论】：

感谢您的链接。你知道 PostgreSQL 是否为即席 SQL 查询缓存查询计划吗？
IIRC，确实如此。不过，我不是 100% 确定。 PostgreSQL 的一个很好的资源是它的邮件列表，主要开发人员在邮件列表中很活跃并回答了很多问题。

【解决方案2】：

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

查询计划不会以任何方式缓存在准备好的语句之外的数据库中。无论如何，如果您没有大量重复使用类似的查询，那么您不太可能使用准备好的语句来缩短查询时间。如果这样做最终会为优化器提供更少的信息来处理，你甚至可能会变得更糟，因为它在知道关于它将要做什么的所有信息之前就已经准备好了。 1000 个字符远不是一个庞大的查询，除非您一次有数百个连接，否则查询解析或规划不太可能是您的问题。可能是锁定问题、糟糕的 VACUUM 程序导致需要搜索以完成任何工作的臃肿数据（在 8.1 上很容易遇到）、缓慢的约束、过多的索引或不考虑移动事物开销的设计完全围绕记忆。查询开销在嫌疑人列表中非常低。

如果您确实有数百个连接，则应该考虑使用连接池。 PostgreSQL 进程的创建非常繁重，在那种环境下它本身并不能很好地发挥作用。

Shoot，您运行的甚至是 8.1 的旧版本，您可能会看到错误； 8.1.4 充满了它们。 8.1.19 是最新的，甚至 8.3.5 已经是当前落后的几个有用的版本升级）。请参阅Versioning Policy，详细了解为什么在几乎所有情况下运行旧版本都比升级风险更大。

【讨论】：