代码改变世界

【PostgreSQL】PostgreSQL 15移除了Stats Collector

2022-08-28 23:11  abce  阅读(701)  评论(0编辑  收藏  举报

试用即将发行的PostgreSQL 15的人会发现少了一个后台进程:​

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 

来和PostgreSQL 14比较一下:​

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的工作内容是什么?

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

 

问题点

由于会话的每个后端都是PostgreSQL中的一个单独进程,因此收集统计信息并传输并不是一件容易的事。每个后端将有关他们所做的活动的信息发送到单个"stats collector"进程。

这种通信过去是通过UDP套接字进行的。这种方法有很多问题,这不是一个可扩展的模型。

用户经常报告不同类型的问题,例如:过时的统计信息、stats collector未运行、autovacuum无法工作/启动等。

 

如果stats collector在特定机器上出现问题,过去真的很难理解出了什么问题。

 

"stats collector"的另一个不利影响是它引起的IO。如果启用DEBUG级别2,可能会看到不断出现在PostgreSQL日志中的消息,例如:​

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)
 

PostgreSQL 15中的新特性

开始使用动态共享内存来收集统计信息,而不再使用文件和文件系统。

 

以前,统计收集器通过UDP接收统计更新,并通过定期将统计数据写入临时文件来共享统计数据。这些文件可以达到数十兆字节,并且每秒最多写入两次。这会阻止我们添加其他有用的统计数据。

 

现在统计信息存储在共享内存中。可变编号对象的统计信息存储在dshash哈希表中(由动态共享内存支持)。固定编号的统计信息存储在普通共享内存中。

 

pgstat.c的头文件包含该架构的概述。

 

不再需要统计信息收集器,将其删除。

 

现在副本删除了已删除对象的统计条目,从完全关闭的副本启动时不再需要重置统计信息。

 

显然,参数stats_temp_directory不见了。因此,我们不需要pg_stat_tmp目录,该目录是在数据目录(或其他位置)中,在该目录生成和读取所有统计文件。然而,仍保留此目录是因为不会破坏许多依赖于该目录的扩展,例如pg_stat_statements。

在加载扩展库之前,目录保持为空。例如,如果我们加载pg_stat_statements库,目录中会出现一个文件。​

$ ls pg_stat_tmp/
pgss_query_texts.stat

当然,扩展不是免费的,他们也有对应的成本。

 

在新架构中,大多数统计更新首先在每个进程中本地累积为"pending"(每个backend都有一个backend本地哈希表)。"pending"是指它们已累积但尚未提交到共享统计系统(shared stats system)。之后会在提交或超时后刷新到共享内存。

 

由于统计数据会在有人尝试读取时同时被更新,因此读取一致性就出现了。因此PostgreSQL 15引入了一个新参数:stats_fetch_consistency,它可以取三个值none、cache 或snapshot​:

·"none"是最有效的。但是,将不会提供读取一致性。但对于大多数使用来说应该没问题。 

·"cache"确保重复访问产生相同的值,这对于涉及例如自连接(self-joins)是有必要的.

·"snapshot"在交互式检查统计信息时很有用,但开销更大。

默认为"cache"

 

如果是在共享内存中,重启后如何保持呢?

在被shutdown之前,检查点进程会将这些统计信息写入文件系统,重启后可以再次被加载。通常,如果是crash了,统计信息就丢失了。

 

这一改动是否会影响我的监控/脚本?

监控视图pg_stat_*会继续起作用。但是,要确保取得是stats_fetch_consistency的恰当的值。如上所述,pg_stat_tmp目录只是为扩展保留的。

 

其它

很多人像我一样,使用postgresql的等待事件来理解postgresql以及会话都把时间花费在哪的人。数据收集和分析工具,比如pg_gather,通过使用等待事件来分析问题。

 

​为了更好地监控postgresql,三个新的等待事件被引入了:

·PgStatsDSA:等待统计动态共享内存分配器访问

·PgStatsHash:等待stats共享内存哈希表访问

·PgStatsData:等待共享内存统计数据访问

 

随着统计收集器的所有开销及其维护的消失,其他子系统(如 autovacuum)要做的工作就更少了。

 

此外,经常查询统计信息的监控工具预计会大大减少系统负载。