【PGCCC】Postgresql BgWriter 原理

前言

postgresql 有一个后台进程 bgwriter,它会定时刷新缓存到文件系统中。这种机制提高了缓存的替换速度,因为在寻找空闲缓存时,有时需要将脏页刷新到文件中,而刷新操作是比较耗时的。同样它也提高了执行 checkpoint 的完成速度,因为 checkpoint 需要刷新所有的脏页。

监控

BgWriter 的监控只能从 pg_stat_bgwriter 视图查看,它只是记录了统计数据

BgWriter 进程

bgwriter 进程的原理很简单,它只是定期的执行缓存刷新。它有两个状态,正常状态和冬眠状态。在正常状态下,bgwriter 在刷新完缓存后,会等待时长bgwriter_delay(可以在postgresql.conf指定,默认值为200ms)。当连续两次都没有要刷新的缓存,那么就会进入冬眠状态,这时的等待时长变为50 * bgwriter_delay。

执行原理

BgWriter 进程会维护了一些统计数据,这些数据会影响到刷新缓存的执行。在介绍下面内容之前,读者需要了解下 clock sweep 缓存替换算法,可以参考此篇文章。

确认遍历数目和位置

postgresql 的缓存是由一个环形数组来表示,clock sweep 算法会记录上次的遍历结束位置和已遍历的缓存轮数。我们把 clock sweep 算法的遍历位置记为strategy_id,缓存轮数记为strategy_pass。当然 bgwriter 也会记录上次的遍历结束位置和遍历轮数,分别记为next_to_clean_id和next_to_clean_passes。

首先确定遍历的缓存数目和起始位置。遍历的方向只能从前往后,并且需要此次 bgwriter 能够遍历到strategy_id。分为下面三种情况:

  1. next_to_clean_passes > strategy_pass 并且 strategy_id >
    next_to_clean_id,那么遍历数目为strategy_id - next_to_clean_id,否则不需要遍历。
  2. next_to_clean_passes == strategy_pass 并且 next_to_clean_id >
    strategy_id,那么遍历数目为NBuffers - (next_to_clean - strategy_buf_id)
  3. 其他情况,遍历数目为NBuffers,起始位置为strategy_id,更新next_clean_id = strategy_id

预估缓存替换数目

bgwriter 还会使用以往的缓存替换数据,来推断此次 bgwriter 的缓存需求数目和。

计算此次 bgwriter 的缓存需求数目,采用了平滑算法,

  1. recent_alloc表示距离上次 bgwrite 期间的缓存需求数
  2. smoothing_samples参数为16,表示平滑程度。
  3. smoothed_alloc表示平滑之后的平均值,初始值为0。
sql 复制代码
if (smoothed_alloc <= (float) recent_alloc)
    // 为了保证此次缓存替换数目大,没有使用平滑算法
    smoothed_alloc = recent_alloc;
else
    // 计算平滑之后的值
    smoothed_alloc += ((float) recent_alloc - smoothed_alloc) / smoothing_samples;

其实 smoothed已经可以作为此次 bgwriter 到下次期间的缓存需求预估值,但是为了应对请求突然增大的情况,这里会再乘以bgwriter_lru_multiplier因子(可以在postgresql.conf配置)

sql 复制代码
// 计算预估值
upcoming_alloc_est = (int) (smoothed_alloc * bgwriter_lru_multiplier);

因为缓存遍历是从next_clean_id开始向后遍历,直到遇到strategy_id为止。而从strategy_id到next_clean_id的这段距离,是有其他进程遍历的,我们需要估算出这部分的可用缓存数量。

通过上次 bgwriter 到此次的统计数据来估算。这里先估算出来找到平均一个可用缓存需要遍历的缓存数目

sql 复制代码
// clock sweep 遍历的缓存数目,缓存数组的长度为NBuffers
strategy_delta = strategy_buf_id - prev_strategy_buf_id;
strategy_delta += (long) passes_delta * NBuffers;

// 计算上次期间的平均遍历数目
scans_per_alloc = (float) strategy_delta / (float) recent_alloc;
// 平滑操作
smoothed_density += (scans_per_alloc - smoothed_density) / smoothing_samples;

strategy_id到next_to_clean_id这段距离,预估的可用缓存数目

sql 复制代码
reusable_buffers_est = (float) (NBuffers - bufs_to_lap) / smoothed_density;

执行完成条件

bgwriter 会从第一步计算出的遍历起始位置,开始遍历。

  1. 如果该缓存的引用次数或使用次数不为零,就会遍历下一个缓存。
  2. 如果该缓存的引用次数或使用次数都为零,认为该缓存是可用缓存。
  3. 如果该缓存为脏页,就刷新到文件并且发送局部sync请求后,也认为该缓存是可用缓存。

当它满足下面三个条件之一,就会认为此次 bgwrite 完成。

  1. 遍历的缓存数目已经达到结束位置(在第一步中确认遍历数目和位置)
  2. 遍历过程中,reusable_buffers_est + 遍历过程中的可用缓存数目 >= upcoming_alloc_est
  3. 刷新的数目超过了bgwriter_lru_maxpages(可以在postgresql.conf中配置)

局部 sync

注意上面的脏页刷新只是写入到了文件系统的cache里,并不代表着持久化到磁盘,所以它会发送局部 sync 请求。当请求量超过了bgwriter_flush_after,就会处理堆积的 sync 请求。注意到这里是局部 sync 请求,它在处理时调用了sync_file_range方法,只是文件中指定的一段内容持久化到磁盘,而不是整个文件。

配置参数

bgwriter_flush_after这个配置项比较特殊,如果没有附带单位,那么表示缓存的个数。如果有,表示缓存的容量。

作者:zhmin

链接:https://zhmin.github.io/posts/postgresql-bg-writer/

#PG证书#PG考试#postgresql培训#postgresql考试#postgresql认证

相关推荐
某个默默无闻奋斗的人16 小时前
高性能 MySQL 进阶:索引核心原理、失效场景与底层优化全解
数据库·mysql
极限实验室18 小时前
INFINI Labs 产品更新 - Easysearch 2.1.0 新增高性能 Rules 规则引擎插件,数据探索 Discover 等
数据库·产品
鹿角片ljp20 小时前
苍穹外卖 day05:店铺营业状态设置与Redis入门实战
数据库·redis·缓存
m0_7434703721 小时前
使用Python进行PDF文件的处理与操作
jvm·数据库·python
Demon_Hao21 小时前
JAVA通过Redis实现Key分区分片聚合点赞、收藏等计数同步数据库,并且通过布隆过滤器防重复点赞
java·数据库·redis
掘根21 小时前
【微服务即时通讯】消息转发子服务
数据库·oracle
喜欢喝果茶.21 小时前
SQL 预处理
数据库·sql
数据科学小丫1 天前
Python 数据存储操作_数据存储、补充知识点:Python 与 MySQL交互
数据库·python·mysql
Knight_AL1 天前
Nacos 启动问题 Failed to create database ’D:\nacos\nacos\data\derby-data’
开发语言·数据库·python
Hoking1 天前
TimescaleDB(PostgreSQL)流复制集群容器化部署(docker-compose)
docker·postgresql·timescaledb·流复制