PostgreSQL vacuum原理—启动机制

在”PostgreSQL vacuum原理一功能与参数中我在致讲了vacuum的几大功能点，以及相关的一些参数，如何来调整vacuum。那么这一章节主要讲比较内核的一些东西。

1.PG发起vacuum的流程

在PG实例起动时，postmaster 进程会fork出autovacuum launcher进程。

完整的vacuum进程创建如下：

pg_ctl命令行起动PG实例，然后fork出postmaster Server进程，这也是PG的主进程。postmaster进程再负责fork各种其它后台进程。

按以下顺序，依次起动：logger进程，checkpoint进程，writer进程，wal writer进程，autovacuum launcher进程以及stats collector进程。

autovacuum launcher进程再负责fork autovacuum worker进程。我们具体的vacuum动作最后都交由worker进程来做，干杂活。

默认情况下，最多由三个worker进程，由参数autovacuum_max_workers控制。

2. autovacuum launcher进程

    autovacuum launcher是vacuum worker的总调度者。在起vacuum worker时，会先balance一次vacuum_cost_limit值，balance的过程就是新的worker起来时，

赋予此worker后面因vacuum而消耗的最大允许IO limit。因为vacuum_cost_limit值是所有worker平摊的，我们设置的vacuum_cost_limit是所有worker的总累加值。

因此新的work加入进来后，需要做两件事：一是计算新的work的cost_limit值；二是调整已经在running的worker的cost_limit值。

另外值得注意的是：从目前源码中得知，vacuum_cost_limit的值是要被vacuum_cost_delay时间平分掉的。假设cost_limit的值是200，cost_delay是10毫秒，max worker是3个，

并且都在running状态。那么可以计算出，其实每个worker每个毫秒所能允许消耗的IO值是：200/10/3，约为6.6。

另外autovacuum launcher还要重建db list，根据autovacuum_naptime去计算每个db分配到的时间。参数介绍请见：”PostgreSQL vacuum原理一功能与参数”另外，

值得注意的是，虽然可以几个worker一起运行，但是目前的做法是，在db 级别并行。也就是说worker是根据autovacuum launcher重建的db list去逐一遍历每个DB的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30088583/viewspace-1601849/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30088583/viewspace-1601849/