PostgreSQL 大表自动 freeze 优化思路

less than 1 minute read

背景

有没有被突发的IO惊到过,有没有见到过大量的autovacuum for prevent wrap。

本文依依解开这些头痛的问题。

1. PostgreSQL 的版本冻结是一个比较蛋疼的事情,为什么要做版本冻结呢?

因为PG的版本号是uint32的,是重复使用的,所以每隔大约20亿个事务后,必须要冻结,否则记录会变成未来的,对当前事务”不可见”。

冻结的事务号是2

src/include/access/transam.h

#define InvalidTransactionId            ((TransactionId) 0)  
#define BootstrapTransactionId          ((TransactionId) 1)  
#define FrozenTransactionId                     ((TransactionId) 2)  
#define FirstNormalTransactionId        ((TransactionId) 3)  
#define MaxTransactionId                        ((TransactionId) 0xFFFFFFFF)  

现在,还可以通过行的t_infomask来区分行是否为冻结行

src/include/access/htup_details.h

/*  
 * information stored in t_infomask:  
 */  
#define HEAP_XMIN_COMMITTED             0x0100  /* t_xmin committed */  
#define HEAP_XMIN_INVALID               0x0200  /* t_xmin invalid/aborted */  
#define HEAP_XMIN_FROZEN                (HEAP_XMIN_COMMITTED|HEAP_XMIN_INVALID)  

表的最老事务号则是记录在pg_class.relfrozenxid里面的。

执行vacuum freeze table,除了修改t_infomask,还需要修改该表对应的pg_class.relfrozenxid的值。

2. 那么系统什么时候会触发对表进行冻结呢?

当表的年龄大于autovacuum_freeze_max_age时(默认是2亿),autovacuum进程会自动对表进行freeze。

freeze后,还可以清除掉比整个集群的最老事务号早的clog文件。

那么可能会出现这样的情形:

可能有很多大表的年龄会先后到达2亿,数据库的autovacuum会开始对这些表依次进行vacuum freeze,从而集中式的爆发大量的读IO(DATAFILE)和写IO(DATAFILE以及XLOG)。

如果又碰上业务高峰,会出现很不好的影响。

3. 为什么集中爆发很常见?

因为默认情况下,所有表的autovacuum_freeze_max_age是一样的,并且大多数的业务,一个事务或者相邻的事务都会涉及多个表的操作,所以这些大表的最老的事务号可能都是相差不大的。

这样,就有非常大的概率导致很多表的年龄是相仿的,从而导致集中的爆发多表的autovacuum freeze。

4. PostgreSQL有什么机制能尽量的减少多个表的年龄相仿吗?

目前来看,有一个机制,也许能降低年龄相仿性,但是要求表有发生UPDATE,对于只有INSERT的表无效。

vacuum_freeze_min_age 这个参数,当发生vacuum或者autovacuum时,扫过的记录,只要年龄大于它,就会置为freeze。因此有一定的概率可以促使频繁更新的表年龄不一致。

5. 那么还有什么手段能放在或者尽量避免大表的年龄相仿呢?

为每个表设置不同的autovacuum_freeze_max_age值,从认为的错开来进行vacuum freeze的时机。

例如有10个大表,把全局的autovacuum_freeze_max_age设置为5亿,然后针对这些表,从2亿开始每个表间隔1000万事务设置autovacuum_freeze_max_age。 如2亿,2.1亿,2.2亿,2.3亿,2.4亿….2.9亿。

除非这些表同时达到 2亿,2.1亿,2.2亿,2.3亿,2.4亿….2.9亿。 否则不会出现同时需要vacuum freeze的情况。

但是,如果有很多大表,这样做可能就不太合适了。

建议还是人为的在业务空闲时间,对大表进行vacuum freeze。

6. 建议

6.1 分区,把大表分成小表。每个表的数据量取决于系统的IO能力,前面说了VACUUM FREEZE是扫全表的, 现代的硬件每个表建议不超过32GB。

6.2 对大表设置不同的vacuum年龄.

alter table t set (autovacuum_freeze_max_age=xxxx);

6.3 用户自己调度 freeze,如在业务低谷的时间窗口,对年龄较大,数据量较大的表进行vacuum freeze。

6.4 年龄只能降到系统存在的最早的长事务即 min pg_stat_activity.(backend_xid, backend_xmin)。 因此也需要密切关注长事务。

Flag Counter

digoal’s 大量PostgreSQL文章入口