使用 pg_stat_statements 收集大型统计集？

Posted 2023-04-19

【中文标题】使用 pg_stat_statements 收集大型统计集？

【英文标题】：Collecting large statistical sets with pg_stat_statements?

【发布时间】：2016-01-03 03:34:17

【问题描述】：

根据 Postgres pg_stat_statements 文档：

模块需要额外的共享内存，与 pg_stat_statements.max。请注意，每当 模块已加载，即使 pg_stat_statements.track 设置为 none。

还有：

代表性查询文本保存在外部磁盘文件中，并且 不消耗共享内存。因此，即使是非常冗长的查询文本 可以保存成功。但是，如果有很多长查询文本 累积起来，外部文件可能会变得难以管理。

从这些中不清楚高 pg_stat_statements.max 的实际内存成本是多少 - 比如说 100k 或 500k（默认为 5k）。设置这么高的水平是否安全，会不会是这样高水平的负面影响？通过 logstash/fluentd 将统计信息汇总到外部数据库中是否是超过特定规模的首选方法？

【参考方案1】：

1.

根据我的阅读，它对查询进行哈希处理并将其保存在 DB 中，将文本保存到 FS。所以下一个问题更值得期待，然后是共享内存过载：

如果积累了很多长查询文本，外部文件可能会增长 大到无法控制

文本的哈希值比文本小得多，我认为您不必担心与长查询相比扩展内存消耗。特别是知道扩展使用查询分析器（这将适用于 EVERY 查询 ANYWAY）：

queryid 哈希值是在解析后分析中计算出来的 查询的表示

我相信将pg_stat_statements.max 设置为大 10 倍应该需要多 10 倍的共享内存。增长应该是线性。 文档中没有这样说，但逻辑上应该是这样。

将设置设置为不同的值是否安全没有答案，因为没有其他配置值和您拥有的硬件的数据。但是由于增长应该是线性的，请考虑以下答案：“如果您将其设置为 5K，并且查询运行时几乎没有增长，那么将其设置为 50K 将几乎不会延长十倍”。顺便说一句，我的问题 - 谁在挖 50000 条慢语句？ :)

2.

这个扩展已经对“dis-valued”语句进行了预聚合。您可以直接在数据库上选择它，因此将数据移动到其他数据库并在那里选择它只会给您带来卸载原始数据库并加载另一个数据库的好处。换句话说，您为原始查询节省了 50MB，但在另一个查询上花费相同。是否有意义？对我来说——是的。这是我自己做的。但我也保存了语句的执行计划（这不是 pg_stat_statements 扩展的一部分）。我相信这取决于你有什么和你有什么。绝对没有必要仅仅因为一些查询。除非你有这么大的文件，否则扩展名可以

如果发生这种情况，作为一种恢复方法，pg_stat_statements 可以选择 丢弃查询文本，因此 pg_stat_statements 视图将显示空查询字段

【讨论】：

我正在运行大量物化视图，因此对pg_stat_statements.max 的要求很高：) 不太担心硬盘空间，主要是内存使用会降低实际查询性能。 > 这是我自己做的。如果可能的话，您能否分享更多关于您的首选设置以及您如何处理从统计收集中卸载主数据库的信息？

大文件威胁不在于硬盘空间，而在于解析它所需的时间。尝试以超级用户（阅读语句表单文件）和非超级用户（没有语句）的身份查询 pg_stat_statements。如果你有大文件，时间会有很大差异。

我所做的是一个修补程序样式设置 - 不是最佳的，但它是：我已将最大值设置为 1000（改为低 5 倍）。我有一个使用 dblink 将 pg_stat_statements 复制到其他数据库的作业（没有查询，但使用它的哈希），以及另一个将哈希和查询发送到不同表（使用 FK）的作业。以及保存当前执行计划并将其发送到带有哈希（FK）的第三个表的另一个作业。这样我就可以比较执行时间和计划是否随时间变化......（Oracle 在 CBO 中内置了类似的东西）

所以基本上我不会从统计收集中卸载主数据库 - 它仍然会收集它并进行所有预聚合。但我使用不同的数据库来保存历史数据和更大量的查询。同时，primary 仅收集其中的 1000 个，并在每个“复制”每小时刷新 em

您如何获取 pg_stat_statement 条目的历史查询计划？