背景

根据之前月报的分析，PostgreSQL中的MVCC机制（详见月报）同时存储新旧版本的元组，对于经常更新的表来说，会造成表膨胀的情况。为了解决这个问题，PostgreSQL 引入了VACUUM和ANALYZE命令，并且引入了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进程一起在下次月报进行分析。