背景

根据之前月报的分析,PostgreSQL中的MVCC机制(详见月报)同时存储新旧版本的元组,对于经常更新的表来说,会造成表膨胀的情况。为了解决这个问题,PostgreSQL 引入了VACUUMANALYZE命令,并且引入了AutoVacuum自动清理。

在PostgreSQL中,AutoVacuum自动清理操作包括:

  • 删除或重用无效元组的磁盘空间
  • 更新数据统计信息,保证执行计划更优
  • 更新visibility map,加速index-only scans (详见文档
  • 避免XID 回卷造成的数据丢失(详见文档

为了实现自动清理,PostgreSQL引入了两种类型的辅助进程:

  • autovacuum launcher
  • autovacuum worker

本文主要分析autovacuum launcher进程相关操作,autovacuum worker比较复杂和重要,我们将在下期月报详细分析。

autovacuum launcher

autovacuum launcher 进程可以理解为AutoVacuum机制的守护进程,周期性地调度autovacuum worker进程。

相关参数

autovacuum launcher 进程在postgresql.conf文件中的相关配置参数(支持对每个表单独配置参数,方法见文档)如下:

  • track_counts:是否开启统计信息收集功能。
  • autovacuum:是否启动系统自动清理功能,默认值为on。
  • autovacuum_max_workers:设置系统自动清理工作进程的最大数量。
  • autovacuum_naptime:设置两次系统自动清理操作之间的间隔时间。
  • autovacuum_vacuum_cost_limit:声明将在自动VACUUM操作里使用的开销限制数值。
  • autovacuum_vacuum_cost_delay :声明如果超过了上面的开销限制,则需要延迟清理的时间。
  • autovacuum_freeze_max_age:设置需要强制对数据库进行清理的XID上限值。
  • autovacuum_multixact_freeze_max_age:设置需要强制对数据库进行清理的multi XID上限值。

因为AutoVacuum依赖于统计信息,所以只有track_counts=on 且autovacuum=on 时,PostgreSQL才启动autovacuum launcher 进程。

autovacuum launcher 进程会周期性地创建autovacuum worker 进程,最多能够创建autovacuum_max_workers个autovacuum worker 进程。我们将会从下面二个方面来分析autovacuum launcher:

  • 执行周期,即autovacuum launcher进程的休眠时间
  • autovacuum worker 调度管理

执行周期

上文的参数autovacuum_naptime决定了autovacuum launcher 的基本执行周期。在PostgreSQL中,理想状态是在autovacuum_naptime的时间内对所有的数据库进行一次清理,即每个数据库希望能够分配到autovacuum_naptime/(数据库的个数) 的时间片去创建一个autovacuum worker进行自动清理。这就要求autovacuum launcher 进程每经过autovacuum_naptime/(数据库的个数) 的时间就要被唤醒,并启动对应的autovacuum worker 进程。

基于此设计思想,autovacuum launcher 进程中维护了一个数据库列表DatabaseList,其中维护了各个database的期望AutoVacuum时间等信息,具体的元素结构如下:

  1. /* struct to keep track of databases in launcher */
  2. typedef struct avl_dbase
  3. {
  4. Oid adl_datid; /* hash key -- must be first */
  5. TimestampTz adl_next_worker;
  6. int adl_score;
  7. dlist_node adl_node;
  8. } avl_dbase;

其中:

  • adl_datid 表示对应database oid,是该Hash表结构的key
  • TimestampTz 表示该database下次将要进行AutoVacuum的时间
  • adl_score 表示该database对应的分值,该分值决定该database启动worker 的时间
  • adl_node 表示该avl_dbase对应的在列表中的位置信息包括:
  1. struct dlist_node
  2. {
  3. dlist_node *prev;
  4. dlist_node *next;
  5. };

当autovacuum launcher初始化时,DatabaseList为空,需要重建,具体步骤如下:

  • 刷新统计信息
  • 建立一个Hash表dbhash存储adl_datid,即数据库ID和avl_dbase(上面的结构体)的对应关系
  • 获取当前所有的数据库和数据库的统计信息,如果存在统计信息且不存在dbhash中,则插入到dbhash中,并将其avl_dbase->adl_score加1,adl_score最后统计存在统计信息且不存在dbhash中的database数量
  • 将Hash 表中的avl_dbase按照adl_score排序,按照顺序给每个database的adl_next_worker赋值为当前时间+每个数据库分到的时间片*其在列表中的顺序。其中每个数据库分到的时间片= autovacuum_naptime/adl_score

可以看出,创建完成之后,DatabaseList中存储按照期望执行自动化清理的时间从大到小排序的数据库信息。

通过分析代码发现,autovacuum launcher进程的执行周期主要是由launcher_determine_sleep 函数来决定的:

  1. 如果autovacuum worker 空闲列表(详见下文autovacuum worker 管理中的分析)为空,autovacuum launcher进程睡眠autovacuum_naptime 后唤醒,否则进行下面的判断
  2. 如果当前DatabaseList不为空,则将DatabaseList列表尾部的数据库期望AutoVacuum的时间戳作为下次唤醒的时间
  3. 除上面之外的情况,用autovacuum_naptime作为执行周期

如果当前的时间已经晚于第2种情况得到的时间戳,则纠正为autovacuum launcher最小的休眠时间100ms。

综上所述,我们知道:

  • autovacuum launcher 基本周期是autovacuum_naptime。如果当前不存在空闲的autovacuum worker,则休眠autovacuum_naptime
  • 在一个autovacuum_naptime工作周期里,每个database 数据库期望占用autovacuum_naptime/adl_score 时间(adl_score可以简单理解为当前存在统计信息的database总数),当该时间到达时,launch a worker,自动清理该数据库

autovacuum worker 管理

因为AutoVacuum的具体过程会消耗数据库资源(比如CPU),可能影响性能,在PostgreSQL中规定,autovacuum launcher可以启动最多autovacuum_max_workers个autovacuum worker 进程。为了管理autovacuum worker 进程,PostgreSQL维护了共享内存AutoVacuumShmemStruct来存储当前所有autovacuum worker的情况,其结构如下:

  1. typedef struct
  2. {
  3. sig_atomic_t av_signal[AutoVacNumSignals];
  4. pid_t av_launcherpid;
  5. dlist_head av_freeWorkers;
  6. dlist_head av_runningWorkers;
  7. WorkerInfo av_startingWorker;
  8. AutoVacuumWorkItem av_workItems[NUM_WORKITEMS];
  9. } AutoVacuumShmemStruct;

其中:

  • av_signal目前是由长度为2的int 数组组成,分别用0,1来表示是否启动worker失败,是否需要重新计算对每个autovacuum worker 的资源限制
  • av_launcherpid代表autovacuum launcher 的pid
  • av_freeWorkers代表空闲的autovacuum woker 相应的WorkerInfoData 列表,WorkerInfoData的具体结构如下:
  1. /*-------------
  2. * This struct holds information about a single worker's whereabouts. We keep
  3. * an array of these in shared memory, sized according to
  4. * autovacuum_max_workers.
  5. *
  6. * wi_links entry into free list or running list
  7. * wi_dboid OID of the database this worker is supposed to work on
  8. * wi_tableoid OID of the table currently being vacuumed, if any
  9. * wi_sharedrel flag indicating whether table is marked relisshared
  10. * wi_proc pointer to PGPROC of the running worker, NULL if not started
  11. * wi_launchtime Time at which this worker was launched
  12. * wi_cost_* Vacuum cost-based delay parameters current in this worker
  13. *
  14. * All fields are protected by AutovacuumLock, except for wi_tableoid which is
  15. * protected by AutovacuumScheduleLock (which is read-only for everyone except
  16. * that worker itself).
  17. *-------------
  18. */
  19. typedef struct WorkerInfoData
  20. {
  21. dlist_node wi_links;
  22. Oid wi_dboid;
  23. Oid wi_tableoid;
  24. PGPROC *wi_proc;
  25. TimestampTz wi_launchtime;
  26. bool wi_dobalance;
  27. bool wi_sharedrel;
  28. int wi_cost_delay;
  29. int wi_cost_limit;
  30. int wi_cost_limit_base;
  31. } WorkerInfoData;
  • av_runningWorkers代表正在运行的autovacuum woker 相应的WorkerInfoData 列表
  • av_startingWorker代表正在启动的autovacuum woker 相应的WorkerInfoData
  • av_workItems存储着一组(256个)AutoVacuumWorkItem。AutoVacuumWorkItem存储着每个autovacuum worker的item 信息。

从上面可以看出,autovacuum launcher中维护三种不同状态的autovacuum worker 进程列表:

  • 空闲的autovacuum worker进程列表
  • 正在启动的autovacuum worker进程
  • 运行中的autovacuum worker进程列表

autovacuum launcher 通过维护AutoVacuumShmemStruct的信息,达到调度autovacuum worker的作用,具体如下:

  • 初始化共享内存时,初始化长度为autovacuum_max_workers的空闲autovacuum worker进程列表。
  • 如果autovacuum launcher进程需要一个worker进程,空闲列表为不空且没有启动中的autovacuum worker进程,则启动一个autovacuum worker进程,并从空闲列表取出一个autovacuum worker 进程,将共享内存中的av_startingWorker赋值为该autovacuum worker的WorkerInfoData。
  • 如果autovacuum worker启动成功,将该autovacuum worker 的WorkerInfoData放入共享内存的av_runningWorkers列表中。
  • autovacuum worker进程退出,将该autovacuum worker 的WorkerInfoData放入共享内存的av_freeWorkers列表中

其中需要注意的是autovacuum launcher进程中只允许存在一个“启动中”状态的autovacuum worker进程,如果启动超时(状态一直为“启动中”时间超过autovacuum_naptime)将被取消启动。autovacuum launcher进程调用launch_worker函数来选择一个database,并为其启动相应的autovacuum worker。launch_worker主要做两件事情:

  • 选取合适的database,并且向postmaster 发送信号创建worker进程
  • 更新该database的期望autovaccum的时间为当前时间+autovacuum_naptime/adl_score

其中,符合下面条件的database将会启动一个worker,进行自动清理:

  • 数据库的最大xid超过配置的autovacuum_freeze_max_age或者最大multixact超过autovacuum_multixact_freeze_max_age。
  • 没有符合上面条件的数据库,则选择数据库列表中最长时间未执行过自动清理操作的数据库。

至此,我们可以概括出autovacuum launcher的大致操作:

  • 调用函数rebuild_database_list,初始化时DatabaseList。DatabaseList保存每个database的laucher期望运行时间等信息
  • 设置进程休眠时间。根据空闲autovacuum worker列表和数据库列表DatabaseList来计算休眠的时间。同时autovacuum launcher休眠也可以被其他信号中断。
  • 处理失败的autovacuum worker进程列表,重新向Postmaster发送信号创建autovacuum worker进程。
  • 处理一直启动的autovacuum worker进程,如果超时,则重置该autovacuum worker信息。
  • 如果DatabaseList为空或者当前时间已经晚于DatabaseList中存储的各个数据库的期望执行autovacuum的最早时间,则会调用launch_worker。launch_worker会去选择合适的数据库并向Postmaster发送信号创建autovacuum worker进程。

总结

经过上面的分析,我们可以得出以下结论:

  • 优先对xid或者multixact 超限的数据库进行自动清理
  • 越长时间没有经过自动清理的数据库优先被清理
  • autovacuum launcher两次启动autovacuum worker的时间间隔不会大于autovacuum_naptime
  • 最多只能启动autovacuum_max_workers个autovacuum worker 进程

除此之外,autovacuum launcher中还涉及到对各个autovacuum_worker的资源限制,这部分内容我们将会和autovacuum_worker进程一起在下次月报进行分析。