PgSQL15 PostgreSQL 15 移除了 Stats Collector

试用即将发行的PostgreSQL 15的人会发现少了一个后台进程： 是的，stats collector 进程没有了。但是去掉这个进程是个好事，一个主要的瓶颈和令人头疼的问题永远消失了。 <!--more--> ## 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日志中的消息，这可能会导致数据目录所在的挂载点产生大量IO。这是参数stats_temp_directory的值所指向的地方。在许多系统上，它将是数据目录中的pg_stat_tmp。 在Ubuntu/Debian上，它将位于/var/run/postgresql中，例如：​ ```shell 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）要做的工作就更少了。 转载： >https://www.cnblogs.com/abclife/p/16634400.html