• 【PostgreSQL】PostgreSQL 15移除了Stats Collector


    试用即将发行的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)要做的工作就更少了。

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

  • 相关阅读:
    打开App显示文件已损坏,打不开,您应该将它移到废纸篓,怎么办?
    Mac下制作openwrt U盘启动盘
    iOS 修改打包后的.ipa应用名字
    使用Aria2+Aria2Ng+OneIndex+OneDrive建立不限流量/离线BT下载/在线观看网盘/在线存储分享平台
    使用微软易升安装纯净版win10
    Mac 配置adb环境变量(为了开Appium)亲测
    CocoaPods 安装及使用(亲测有效)
    1.6 MySQL 基础教程
    Rhythmk 一步一步学 JAVA (19) JAVA IO 文件常用操作
    Rhythmk 一步一步学 JAVA (18) Axis2 创建 WebService
  • 原文地址:https://www.cnblogs.com/abclife/p/16634400.html
Copyright © 2020-2023  润新知