【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)要做的工作就更少了。
此外,经常查询统计信息的监控工具预计会大大减少系统负载。