背景

最近处理了几起线上实例表膨胀的问题。表膨胀是指表的数据和索引所占文件系统的空间,在有效数据量并未发生大的变化的情况下,不断增大。PG使用过程中需要特别关注这方面,我们来给大家解析一下表膨胀的原因。

表膨胀的直接触发因素是表上的大量更新,如全表的update操作、大量的insert+delete操作等。而我们知道,PG在更新数据时,是不直接删除老数据的。一个update操作执行后,被更改的数据的旧版本也被保留下来,直到对表做vacuum操作的时候,才考虑回收旧版本。做数据更新时,这些旧版本不及时回收就会造成表膨胀。

线上实例都配置了autovacuum,有了autovacuum,PG会定期自动启动autovacuum worker进程,执行vacuum回收旧版本,防止表膨胀。但在我们看到的几起表膨胀问题里面,autovacuum几乎每分钟运行一次,仍然没有避免表膨胀,这是为什么呢?

表膨胀问题的重现

从问题实例的pg_stat_activity视图里面,可以发现它们有一个特点,就是有长时间未提交或终止的事务。

我们用下面的例子简单模拟一下。先创建一张表,插入一条数据。再建立两个连接,其中一个开启一个事务,执行插入和查询,但不提交;另一个不断执行update操作。

控制台A:

postgres=# begin;
BEGIN
postgres=# insert into test_bloat values(1);
INSERT 0 1
postgres=# select * from test_bloat;
 a
---
 1
 1
(2 rows)


postgres=#

控制台B:

postgres=# update test_bloat set a = 1;
UPDATE 1
postgres=# \watch 1
Watch every 1s	Wed Nov 11 17:04:31 2015
....

过不多久,查看表的大小就会发现它不断增大:

postgres=# \dt+ test_bloat
                           List of relations
 Schema |    Name    | Type  |     Owner     |    Size    | Description
--------+------------+-------+---------------+------------+-------------
 public | test_bloat | table | guangzhou.zgz | 8192 bytes |
(1 row)

....

postgres=# \dt+ test_bloat
                         List of relations
 Schema |    Name    | Type  |     Owner     | Size  | Description
--------+------------+-------+---------------+-------+-------------
 public | test_bloat | table | guangzhou.zgz | 40 kB |

查看第一个连接中的事务状态如下:

postgres=# select * from pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid            | 13003
datname          | postgres
pid              | 113306
usesysid         | 10
usename          | guangzhou.zgz
application_name | psql
client_addr      |
client_hostname  |
client_port      | -1
backend_start    | 2015-11-11 16:45:38.452728+08
xact_start       | 2015-11-11 16:47:00.998929+08
query_start      | 2015-11-11 16:47:43.657035+08
state_change     | 2015-11-11 16:47:43.658001+08
waiting          | f
state            | idle in transaction
backend_xid      | 2431157
backend_xmin     |
query            | select * from test_bloat;

可以发现,它有两个特点:

  1. 它的状态为“idle in transaction”,这是因为它未提交,又没有正在进行的查询;
  2. 它的backend_xid不为空,即它有事务号,这是因为它执行了更新操作,插入了一条数据。注意,PG只在发生更新的时候才分配事务ID,没有执行更新操作的事务(即只读事务)是没有backend_xid的。

测试发现,如果及时将此种事务提交,并不会造成表膨胀。可见正是这些事务导致了旧版本无法回收!

为什么旧版本没有被回收

我们从代码里面看看,为什么长事务阻止了版本回收?先看看vacuum回收旧版本的代码。vacuum操作由autovacuum worker执行,其调用顺序如下:

vacuum->vacuum_rel->lazy_vacuum_rel->lazy_scan_heap->heap_page_prune -> heap_prune_chain

vacuum每次处理一个表;每个表同时只有一个进程进行vacuuum。其中,lazy_scan_heap扫描一个表的所有页面,对每个页面调用heap_page_prune进行处理。heap_page_prune调用heap_prune_chain函数来判断,一个旧版本是否可以被回收(即删除)。这里要考虑的一个重要因素是,旧版本是否可能被当前系统里正在进行的事务(活跃事务,即已开始但未提交或终止的事务)需要。heap_prune_chain调用了HeapTupleSatisfiesVacuum来对一个数据记录的旧版本(tuple)做这个判断。HeapTupleSatisfiesVacuum里面最重要的一个判断如下:

if (!TransactionIdPrecedes(HeapTupleHeaderGetRawXmax(tuple), OldestXmin))
	return HEAPTUPLE_RECENTLY_DEAD;

这个判断实际上是计算当前tuple的xmax是否大于或等于OldestXmin。我们知道,xmax是删除这个tuple的事务ID,而OldestXmin由GetOldestXmin函数计算,是所有活跃事务的ID,以及所有事务的xmin 组成的集合中最小的事务ID。所有ID大于这个OldestXmin的事务,都是“新近”开启的事务,其他事务可能需要读取这个旧版本用于查询,所以不能物理删除,则返回HEAPTUPLE_RECENTLY_DEAD,保留此tuple(即不回收)。但如果系统中含有很久之前开启而未提交的事务,并且这个事务由于执行过更新,创建了事务ID(成为“长事务”),那么OldestXmin会非常小,vacuum做上述这个判断时,结果通常为true,即返回HEAPTUPLE_RECENTLY_DEAD,这样heap_prune_chain将会保留此tuple(旧版本),导致回收无法完成,表膨胀由此发生。

需要注意的是,并不是只有更新过数据的事务,长时间不提交会造成表膨胀,只读的事务也是同样的!看下面的case:

控制台A:

postgres=# begin;
BEGIN
postgres=# declare c1 cursor for select * from test_bloat for read only;
DECLARE CURSOR
postgres=#

控制台B:

postgres=# select * from pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------------------------------------
datid            | 13003
datname          | postgres
pid              | 110811
usesysid         | 10
usename          | guangzhou.zgz
application_name | psql
client_addr      |
client_hostname  |
client_port      | -1
backend_start    | 2015-11-12 11:01:00.880549+08
xact_start       | 2015-11-12 11:01:32.843927x+08
query_start      | 2015-11-12 11:01:33.87293+08
state_change     | 2015-11-12 11:01:33.873547+08
waiting          | f
state            | idle in transaction
backend_xid      |
backend_xmin     | 2436509
query            | declare c1 cursor for select * from test_bloat for read only;

我们看到,这个只读事务的xmin是非空的,会被用来做OldestXmin,如果它长时间不完成操作(即cursore不close),就会造成整个数据库的表膨胀!因此,即便是只读事务,也要及时提交;另外,避免在存在大量更新操作的实例上,跑运行时间很长的查询语句。

回收膨胀的空间

如何回收膨胀的空间?长事务结束后,vacuum会回收一部分旧版本。但它回收数据页内的旧版本后,一般情况下并不能把空间还给操作系统。就是说,表所占的空间没有变化。只有一种情况下,即回收的页处于存储数据的文件(一张表对应一个或多个文件)尾部,并且页内没有事务可见的tuple(即整个页都可以删除)时,会做truncate操作,把尾部的这些页统一从文件中删除,文件大小和表所占空间随之减少。

另一种回收膨胀空间的方法是,执行vacuum full <table name> 操作。vacuum full命令实际上重建了整张表和上面的索引。它的缺点是,需要长时间锁住整张表,并耗费大量的IO,对应用影响很大。要减少vacuum full锁住表的时间,可以使用社区提供的pg_repack工具。它的原理是基于原表创建一张新表,同时利用触发器,将原表上当前的增量更新不断记录下来。新表建好后,将所记录的增量更新应用到新表,直到新旧表数据完全一致。最后将新旧表表名互换,删除旧表,即完成了表的空间整理操作,回收了空间。

避免表膨胀的方法

上面看到,表一旦膨胀,空间很难回收回来,所以要尽可能的避免表膨胀。要避免表膨胀,需要注意:

  1. 尽早的、及时的提交事务;
  2. 设计应用时,要使事务尽量短小;
  3. 注意配置与应用规模相适应的硬件资源(IO能力、CPU、内存等),并调教好数据库,使其性能最优,避免有些事务因为资源或性能问题长时间无法完成;
  4. 提交autovacuum,使其能按合理的周期运行。这方面的内容,我们今后专门介绍;
  5. 定期监控系统中是否有长事务,可以使用下面的SQL监控持续时间超过一定时间的事务:
select * from pg_stat_activity where state<>'idle' and pg_backend_pid() != pid and (backend_xid is not null or backend_xmin is not null ) and extract(epoch from (now() - xact_start))  > <时间阈值,单位秒> ;

只要运用好上述方法,表膨胀是可以有效控制的。正常的表膨胀不会超过原来数据量的20%。

螃蟹在剥我的壳,笔记本在写我,漫天的我落在枫叶上雪花上,而你在想我。 --章怀柔