背景
根据之前月报的分析，PostgreSQL中的MVCC机制（详见月报）同时存储新旧版本的元组，对于经常更新的表来说，会造成表膨胀的情况。为了解决这个问题，PostgreSQL 引入了VACUUM和ANALYZE命令，并且引入了AutoVacuum自动清理。
在PostgreSQL中，AutoVacuum自动清理操作包括：
为了实现自动清理，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 函数来决定的：
- 如果autovacuum worker 空闲列表（详见下文autovacuum worker 管理中的分析）为空，autovacuum launcher进程睡眠autovacuum_naptime 后唤醒，否则进行下面的判断
- 如果当前DatabaseList不为空，则将DatabaseList列表尾部的数据库期望AutoVacuum的时间戳作为下次唤醒的时间
- 除上面之外的情况，用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进程一起在下次月报进行分析。
