摘要:以前,统计信息收集器通过UDP接收统计信息更新,并通过定期将统计信息数据写出到临时文件来共享统计信息数据。当文件达到数十兆字节时,每秒最多写出两次,这会阻止添加其他有用的统计数据。现在,PostgreSQL 15将做出了重大的改变,开始使用动态共享内存来收集统计信息,而不再使用文件和文件系统。
https://www.percona.com/blog/postgresql-15-stats-collector-gone-whats-new/
声明:本文为CSDN翻译,转载请注明来源。
作者 | Jobin Augustine
译者 | 朱珂欣 责编 | 屠敏
出品 | CSDN(ID:CSDNnews)
众所周知,PostgreSQL是一个功能强大的开源对象关系数据库系统,它使用并扩展了SQL语言,并结合了许多可安全存储和扩展最复杂数据工作负载的特性。一直以来,PostgreSQL都在业内拥有极高的声誉,它的每一次版本的发布,都能在国内外获得很大的关注度。
2022年6月30日,PostgreSQL全球开发组宣布PostgreSQL 15的第二个beta版本已可供下载,该版本包含将于2022年末发布的PostgreSQL 15正式版本中的所有特性和功能。
很多人将PostgreSQL 15与PostgreSQL 14相比较,就会发现有一个特别的更新——"统计信息收集器"不见了。曾经是无数开发者的开发瓶颈,如今已经永远消失了。作为PostgreSQL 14和更早版本都需要“统计信息收集器”,它存在怎样的问题呢?PostgreSQL 15又新增了什么样的功能?
被舍弃的统计信息收集器
PostgreSQL的统计信息收集器,是一个支持收集和报告服务器活动信息的子系统。它可以对表和索引的访问计数,以此累计统计信息。并且,还可以跟踪每个表中的总行数、每个表的清理和分析动作的信息,以及统计调用用户定义函数的次数和在每次调用中花费的总时间。
但是,PostgreSQL的统计信息收集器同样存在一些问题。
信息传输受到阻力。
由于会话的每个后端是PostgreSQL中的单独进程,因此,收集统计信息并传输并不是容易的事。每个后端将有关它们执行的活动信息发送到单个“统计信息收集器”进程。在过去,这种通信是通过UDP套接字进行,在用户报告的不同类型问题中显示,有三类问题较为明显:统计数据过期;统计数据收集器不运行;自动真空不工作/不启动等。
并且,在过去如果统计数据收集器在特定机器上出现问题,用户其实很难理解出了什么问题。
大量IO出现。
“统计信息收集器”还有一个不利影响——它引起的IO。如果启用DEBUG级别 2,可能会看到不断出现在PostgreSQL 日志中的消息,将导致数据目录所在的装入点上出现大量 IO。
下图是参数值stats_temp_directory所指向的位置。在许多系统上,它将是数据目录中pg_stat_tmp。在Ubuntu/Debian上,它将在/var/run/postgresql中,例如:
PostgreSQL 15中的新动作
面对统计信息收集器带来的弊端,如今,PostgreSQL 15开始使用动态共享内存来收集统计信息,而不再使用文件和文件系统。
正如Andres Freund在文中提及的:
以前,统计信息收集器通过UDP接收统计信息更新,并通过定期将统计信息数据写出到临时文件来共享统计信息数据。这些文件可以达到数十兆字节,并且每秒最多写出两次。这会阻止我们添加其他有用的统计数据。 现在,统计信息都存储在共享内存中。可以变化的编号对象的统计信息,存储在由动态共享内存支持的 dshash 哈希表中。固定编号的统计信息,存储在普通共享内存中。pgstat.c 的标题包含体系结构的概述。 不再需要统计信息收集器,请将其删除。
显然,参数stats_temp_directory已经消失。因此,不再需要pg_stat_tmp目录了,pg_stat_tmp目录是在数据目录或其他位置中创建的,所有统计文件都在此生成和读取。然而,仍保留它是因为不会破坏许多依赖于该目录的扩展,例如pg_stat_statements。
在加载扩展库之前,目录保持为空。例如,如果我们加载pg_stat_statements库,目录中会出现一个文件。
当然,这些扩展都并非免费的,需要成本。
在新架构中,大多数统计更新时,首先需要在每个进程中本地累积为"pending"(每个后端都有一个后端本地哈希表)。"pending"是指已累积但尚未提交到共享统计系统的待定信息。在提交后或超时后,会被刷入共享内存。
由于统计信息是在有人试图读取时被并发更新的,所以读取一致性就成了问题。为了解决读取一致性的问题=PostgreSQL 15引入了一个新的参数:stats_fetch_consistency。它可以取三个值,none、cache 、snapshot:
“none”是最有效的。如果存在期望的监视查询,则无法提供读取一致性。但对于大多数使用来说是可以的。
“cache ”能确保重复访问产生相同的值,对于涉及自联接的查询很重要。
“snapshot”在以交互方式检查统计信息时很有用,但开销更高。
stats_fetch_consistency的默认值为“cache ”。
更新迭代中的疑问与解答
面对PostgreSQL 15新版本中的重大调整,很多用户也会产生相关的疑惑。
统计信息位于共享内存中,如何在重新启动后保存?
统计信息在关机前,由检查点进程写出到文件系统,并在启动期间由启动进程再次装回。像往常一样,如果发生崩溃,统计信息将会失效。
新功能会影响监控工具/脚本吗?
显然是不会,所有的统计监测视图pg_stat_*仍能照常工作,但需要为stats_fetch_consistency选择适当的值。如上所述,保留pg_stat_tmp目录是为了不破坏使用这种方法开发的扩展。但是,扩展开发人员需要针对PostgreSQL 15彻底测试扩展。
如何使用PostgreSQL等待事件,了解PostgreSQL及其会话在哪里花费的时间呢?
日常生活中使用的数据收集和分析工具,例如pg_gather,利用这些等待事件分析和了解问题。 因此,为了更好地监控,PostgreSQL还引入了三个新的等待事件。
PgSta tsDSA: 等待统计动态共享内存分配器访问。
PgStatsHash: 等待stats共享内存哈希表访问。
PgStatsData: 等待共享内存统计数据访问。
总的来说,PostgreSQL 15不再需要统计信息收集器,而是将统计信息都存储在共享内存中。随着统计收集器及其维护的所有开销的消失,其他子系统,例如自动真空系统,工作量将大大减少,经常查询统计信息的监控工具将会大大降低系统的负载。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.