---

title: PgSQL · 源码分析 · AutoVacuum机制之autovacuum launcher

author: 卓刀

背景

根据之前月报的分析，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时间等信息，具体的元素结构如下：

/* struct to keep track of databases in launcher */
typedef struct avl_dbase
{
    Oid            adl_datid;        /* hash key -- must be first */
    TimestampTz adl_next_worker;
    int            adl_score;
    dlist_node    adl_node;
} avl_dbase;

其中：

• adl_datid 表示对应database oid，是该Hash表结构的key
• TimestampTz 表示该database下次将要进行AutoVacuum的时间
• adl_score 表示该database对应的分值，该分值决定该database启动worker 的时间
• adl_node 表示该avl_dbase对应的在列表中的位置信息包括：

struct dlist_node
{
    dlist_node *prev;
    dlist_node *next;
};

当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的情况，其结构如下：

typedef struct
{
    sig_atomic_t av_signal[AutoVacNumSignals];
    pid_t        av_launcherpid;
    dlist_head    av_freeWorkers;
    dlist_head    av_runningWorkers;
    WorkerInfo    av_startingWorker;
    AutoVacuumWorkItem av_workItems[NUM_WORKITEMS];
} AutoVacuumShmemStruct;

其中：

• av_signal目前是由长度为2的int 数组组成，分别用0，1来表示是否启动worker失败，是否需要重新计算对每个autovacuum worker 的资源限制
• av_launcherpid代表autovacuum launcher 的pid
• av_freeWorkers代表空闲的autovacuum woker 相应的WorkerInfoData 列表，WorkerInfoData的具体结构如下：

/*-------------
 * This struct holds information about a single worker's whereabouts.  We keep
 * an array of these in shared memory, sized according to
 * autovacuum_max_workers.
 *
 * wi_links        entry into free list or running list
 * wi_dboid        OID of the database this worker is supposed to work on
 * wi_tableoid    OID of the table currently being vacuumed, if any
 * wi_sharedrel flag indicating whether table is marked relisshared
 * wi_proc        pointer to PGPROC of the running worker, NULL if not started
 * wi_launchtime Time at which this worker was launched
 * wi_cost_*    Vacuum cost-based delay parameters current in this worker
 *
 * All fields are protected by AutovacuumLock, except for wi_tableoid which is
 * protected by AutovacuumScheduleLock (which is read-only for everyone except
 * that worker itself).
 *-------------
 */
typedef struct WorkerInfoData
{
    dlist_node    wi_links;
    Oid            wi_dboid;
    Oid            wi_tableoid;
    PGPROC       *wi_proc;
    TimestampTz wi_launchtime;
    bool        wi_dobalance;
    bool        wi_sharedrel;
    int            wi_cost_delay;
    int            wi_cost_limit;
    int            wi_cost_limit_base;
} 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进程一起在下次月报进行分析。