PostgreSQL 15：统计收集器不见了？

开源软件联盟PostgreSQL分会 2022-09-07

651

任何尝试即将推出的 PostgreSQL 15 的人都可能会发现其中一个后台进程消失了。

1 postgres    1710       1  0 04:03 ?        00:00:00 /usr/pgsql-15/bin/postmaster -D /var/lib/pgsql/15/data/
2 postgres    1711    1710  0 04:03 ?        00:00:00 postgres: logger 
3 postgres    1712    1710  0 04:03 ?        00:00:00 postgres: checkpointer 
4 postgres    1713    1710  0 04:03 ?        00:00:00 postgres: background writer 
5 postgres    1715    1710  0 04:03 ?        00:00:00 postgres: walwriter 
6 postgres    1716    1710  0 04:03 ?        00:00:00 postgres: autovacuum launcher 
7 postgres    1717    1710  0 04:03 ?        00:00:00 postgres: logical replication launcher

对比PostgreSQL 14进程列表

1 postgres    1751       1  0 04:04 ?        00:00:00 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/
2 postgres    1752    1751  0 04:04 ?        00:00:00 postgres: logger
3 postgres    1754    1751  0 04:04 ?        00:00:00 postgres: checkpointer
4 postgres    1755    1751  0 04:04 ?        00:00:00 postgres: background writer
5 postgres    1756    1751  0 04:04 ?        00:00:00 postgres: walwriter
6 postgres    1757    1751  0 04:04 ?        00:00:00 postgres: autovacuum launcher
7 postgres    1758    1751  0 04:04 ?        00:00:00 postgres: stats collector
8 postgres    1759    1751  0 04:04 ?        00:00:00 postgres: logical replication launcher

是的，“统计收集器”不见了，而且永远消失了。主要的瓶颈和头痛问题已经一去不复返了。

统计数据收集器是做什么的？

新手用户可能想知道它是什么以及为什么 PG 14 和更早版本需要它。至少有一些用户对用于查询计划的表级统计信息收集 (ANALYZE) 感到困惑。PostgreSQL 跟踪每个进程的所有活动以获得累积统计信息，例如扫描表或索引的次数，或者最后一次清理或自动清理在表上运行的时间，或者自动清理在表上运行的次数等。所有信息统计收集器收集的数据可通过不同的 pg_stat_* 视图获得。

带来了什么问题？

由于会话的每个后端都是 PostgreSQL 中的一个单独进程，因此收集统计信息并传输它们不是一件容易的事。每个后端将有关他们所做的活动的信息发送到单个“统计信息收集器”进程。这种通信过去是通过UDP套接字进行的。这种方法有很多问题，这不是一个可扩展的模型。用户经常报告不同类型的问题，例如1、过时的统计信息；2、stats collector 未运行、3. autovacuum 无法工作/启动等。

如果统计数据收集器在特定机器上出现问题，过去真的很难理解出了什么问题。
“统计收集器”的另一个不利影响是它引起的 IO。如果您启用 DEBUG 级别 2，您可能会看到不断出现在 PostgreSQL 日志中的消息，例如：

1 2022-08-22 03:49:57.153 UTC [736] DEBUG:  received inquiry for database 0
2 2022-08-22 03:49:57.153 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/global.stat"
3 2022-08-22 03:49:57.153 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"
4 2022-08-22 03:49:57.168 UTC [1278] DEBUG:  autovacuum: processing database "postgres"
5 2022-08-22 03:49:57.168 UTC [736] DEBUG:  received inquiry for database 13881
6 2022-08-22 03:49:57.168 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/global.stat"
7 2022-08-22 03:49:57.168 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_13881.stat"
8 2022-08-22 03:49:57.169 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"

这可能会导致数据目录所在的挂载点产生大量 IO。

这是stats_temp_directory参数值所指向的地方。在许多系统上，pg_stat_tmp位于数据目录中。

在 Ubuntu/Debian 上，它将位于/var/run/postgresql中，例如：

1 postgres=# show stats_temp_directory ;
2       stats_temp_directory          
3 -----------------------------------------
4 /var/run/postgresql/14-main.pg_stat_tmp
5 (1 row)

PostgreSQL 15 有什么新功能？

现在，统计信息不再使用文件和文件系统，而是使用动态共享内存。
您可以参考Andres Freund在此处

（相关链接:https://git.postgresql.org/gitweb/?p=postgresql.git,h=5891c7a8e）提交的摘要：

以前，统计收集器通过 UDP 接收统计更新，并通过定期将统计数据写入临时文件来共享统计数据。这些文件可以达到数十兆字节，并且每秒最多写入两次。这一再阻止我们添加其他有用的统计数据。
现在统计信息存储在共享内存中。可变编号对象的统计信息存储在 dshash 哈希表中（由动态共享内存支持）。固定编号的统计信息存储在普通共享内存中。
pgstat.c的头文件包含架构的概述。
不再需要统计信息收集器，是时候忘记它了。
通过利用先前提交中引入的事务性统计信息删除基础设施，统计信息条目不再“泄漏”了。从 [auto-]vacuum 调用的 pgstat_vacuum_stat() 删除了以前泄露的统计信息。在有许多小表的系统上，pgstat_vacuum_stat()可能是相当的昂贵的。
现在副本删除了已删除对象的统计条目，从完全关闭的副本开始时不再需要重置统计信息。

显然，参数stats_temp_directory已经没有了。因此我们不需要pg_stat_tmp，该目录是在生成和读取所有stats文件的数据目录(或其他位置)中创建的。但是，保留这个目录是为了不破坏许多扩展功能，比如pg_stat_statements，这些扩展依赖于该目录。在加载扩展库之前，该目录一直为空。例如，如果加载pg_stat_statements库，则目录中会出现一个文件。

1  $ ls pg_stat_tmp/
2  pgss_query_texts.stat

当然，扩展不是免费的。他们承担自己的成本。

在新架构中，大多数统计更新首先在每个进程中本地累积为“待处理”（每个后端都有一个后端本地哈希表）。“待定”是指它们已累积但尚未提交到共享统计系统。这稍后会再提交或超时后刷新到共享内存。

由于当有人试图读取数据时，数据会同时更新，读取一致性就成了问题。因此，PostgreSQL 15引入了一个新参数:stats_fetch_consistency，它可以接受三个值:none, cache或snapshot。“none”是最有效的。但是，如果有监视查询期望读取一致性，那么就不能提供读取一致性。但是对于大部分的使用应该是可以的。“cache”确保重复访问产生相同的值，这对于自连接等查询是必不可少的。“snapshot”在交互式检查统计数据时很有用，但开销较高。默认为“cache”。

如果它在共享内存中，如何在重新启动后幸存下来？

统计信息在关机前由检查指针进程写出到文件系统，并在启动进程启动期间再次加载回。像往常一样，如果发生崩溃，统计信息将被丢弃。

这会影响我的监控工具/脚本吗？

所有的统计监视视图pg_stat_*将继续工作。但是，请确保为stats_fetch_consistency选择合适的值。如上所述，保留pg_stat_tmp目录是为了不破坏使用这种方法开发的扩展功能。然而，扩展开发人员需要根据PostgreSQL 15对扩展进行彻底的测试。

还有什么？

像我这样的人使用PostgreSQL的等待事件来了解PostgreSQL和它的会话在哪里花费了时间。像我们日常中使用的pg_gather这样的数据收集和分析工具，利用这些等待事件分析来理解问题。为了更好地监视，引入了三个新的等待事件。

PgStatsDSA	等待统计动态共享内存分配器访问
PgStatsHash	等待统计共享内存哈希表访问
PgStatsData	等待共享内存统计数据访问

随着统计收集器的所有开销及其维护的消失，其它子系统（如 autovacuum）要做的工作就更少了。此外，经常查询统计信息的监控工具预计会大大减少系统负载。

感谢社区

感谢整个 PostgreSQL 社区，尤其是黑客，为这个惊人的改进做出的贡献。整个讨论始于四年前，当时堀口京太郎开始讨论这个想法和补丁。它最终由 Andres Freund、Melanie Plageman 和团队努力的工作实现。我们可以看到，这确实是许多贡献者的出色团队合作，如 Alvaro Herrera、David G Johnston、Thomas Munro、Tomas Vondra、Arthur Zakirov、Antonin Houska、Justin Pryzby、Tom Lane、Fujii Masao、Greg Stark、Robert Haas、Stephen Frost、 Bertrand Drouvot、Magnus Hagander 和许多其他人。现在是庆祝 PostgreSQL 在获得更多功能的同时变得苗条和精简的时候了。