[译]PostgreSQL 15: stats collector进程优化掉了

PostgreSQL 15: stats collector进程优化掉了

PG15对统计进行了重大改进。将stats collector进程优化掉了，不再将统计数据放入临时文件中，而是放到共享内存中，在shutdown前由checkpoint进程将其持久化，启动时由startup进程将其加载。减少了IO和进程间通信，从而改进性能。

正文

尝试使用PG15的用户都会发现有一个后台进程消失了：

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

PG14及其之前的版本：

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

是的，“stats collector”消失了。主要瓶颈一去不复返了。

Stats collector进程作用？

新手用户可能想知道这个进程是什么？为什么PG14及之前版本需要。有一些用户可能还会和对用于查询计划的表级统计信息采集（ANALYZE）感到迷惑。但这是不同的。PG跟踪每个进程的所有活动以获得累积统计信息，例如扫描表或索引的次数，或者最后一次vacuum或自动vacuum在表上的运行时间，或者自动vacuum在表上运行次数。所有信息统计收集的数据可以通过不同的pg_stat_*视图获得。

有什么问题？

会话的每个后台进程都是一个独立的PG进程，采集统计信息和传输不是一个简单的任务。每个后台进程将他们的活动信息发送给单独的“stats collector”进程。通过UDP包进行通信。这种方法有很多问题，不是一个可扩展的模型。用户经常报告不同类型的问题，如1）过时的统计信息，2）stats collector未运行，3）autovacuum无法工作/启动等。

如果stats collector在某一个机器上发生问题，很难解释理解出了什么问题。

Stats collector另一个缺点是它引起的IO。如果启用DEBUG级别2，可以在日志中看到：

2022-08-22 03:49:57.153 UTC [736] DEBUG: received inquiry for database 0
2022-08-22 03:49:57.153 UTC [736] DEBUG: writing stats file "pg_stat_tmp/global.stat"
2022-08-22 03:49:57.153 UTC [736] DEBUG: writing stats file "pg_stat_tmp/db_0.stat"
2022-08-22 03:49:57.168 UTC [1278] DEBUG: autovacuum: processing database "postgres"
2022-08-22 03:49:57.168 UTC [736] DEBUG: received inquiry for database 13881
2022-08-22 03:49:57.168 UTC [736] DEBUG: writing stats file "pg_stat_tmp/global.stat"
2022-08-22 03:49:57.168 UTC [736] DEBUG: writing stats file "pg_stat_tmp/db_13881.stat"
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，例如：

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

PG15新功能

现在，统计信息不再使用文件和文件系统，而是使用动态共享内存。可以参考Andres Freund的commit摘要：

以前，stats collector通过UDP接收统计更新，并通过定期将统计数据写入临时文件来共享统计数据。这些文件可以达到数十兆字节，冰箱每秒最多写入2次。这就一再阻止我们添加其他有用的统计数据。

现在统计数据存储在共享内存。variable-numbered对象统计信息存储在以dshash哈希表中（动态共享内存）。Fixed-numbered统计存储在普通共享内存中。

Pgstat.c的头文件中有架构的概述。Stats collector不再需要了，可以移除。

利用事务统计丢掉infrastructure（之前commit统计条目引入）不能再泄漏。之前通过pg_stat_vacuum_stat()删除泄漏的统计（被[auto-]vacuum调用）。在有许多小表的系统中pgstat_vacuum_stat()代价非常昂贵。

现在对于删除的对象，副本删除统计信息条目，当从一个干净的shut down副本开始就不再需要进行统计重置。

很明显，stats_temp_directory参数弃用了。我们不再需要pg_stat_tmp目录。但是，保留这个目录不会破坏pg_stat_statements类似的插件使用。他们依赖于这个目录。例如，我们加载pg_stat_statements库，目录中会出现一个文件：

$ ls pg_stat_tmp/
pgss_query_texts.stat

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

由于统计数据会在有人尝试阅读时同时更新。因此就出现了读取一致性问题。所以PG15引入了一个新参数stats_fetch_consistency，可以取值none，cache或snapshot。

“none”是最高效的，但不会提供一致性读。“cache”确保字段能够重复访问到相同值，在self-join相关的查询中非常必要。“snapshot”在交互式检查统计信息时很有用，但开销较大。默认是“cache”。

如果他在共享内存，如果在重启后沿用

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

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

所有统计数据监控视图pg_stat_*继续按原样工作。但请确保为stat_fetch_consistency。如上所述，保留pg_stat_tmp目录不会破坏使用这种方法开发的插件。但是插件开发人员需要针对PG15彻底进行测试。

还有什么

像我这样使用PG　wait events来了解PG和他的会话在哪里花费了时间。我们在日常生活中使用pg_gather类似的数据采集分析工具。引入了3个新的等待事件：

随着stats collector的所有开销及维护的消失，其他子进程例如autovacuum要做的工作就更少了。

原文

https://www.percona.com/blog/postgresql-15-stats-collector-gone-whats-new/