postgresql dead_tuple和live_tuple

  1. 云栖社区>
  2. 博客>
  3. 正文

postgresql dead_tuple和live_tuple

流浪的猫666 2018-12-19 10:35:46 浏览5134
展开阅读全文

-PG并没有像Oracle那样的undo来存放旧版本;而是将旧版本直接存放于relation文件中。那么带来的问题就是dead tuple过多,导致relation文件不断增大而带来空间膨胀问题。

--为了解决这个问题,PG中引入了vacuum后台进程,专门来清理这些dead tuple,并回缩空间

postgres=# create table t (id int ,name varchar(50));
CREATE TABLE
postgres=# insert into t select id,'rudy'|| id from generate_series(1,100) id;
INSERT 0 100
postgres=# select relname,n_live_tup,n_dead_tup from pg_stat_user_tables where relname='t';

relname n_live_tup n_dead_tup
t 100 0

(1 行记录)

--由以下可知,没更新一次,n_dead_tup加1
postgres=# update t set name='dead tuple' where id=1;
UPDATE 1
postgres=# select relname,n_live_tup,n_dead_tup from pg_stat_user_tables where relname='t';

 relname n_live_tup n_dead_tup 
 t              100          1

postgres=# update t set name='dead tuple 2' where id=1;          
UPDATE 1
postgres=# select relname,n_live_tup,n_dead_tup from pg_stat_user_tables where relname='t';

 relname n_live_tup n_dead_tup 
 t              100          2

 
 
--每删除一次数据 n_live_tup 和 n_dead_tup 均加1 
postgres=# delete from  t where id<10;
DELETE 9
postgres=# select relname,n_live_tup,n_dead_tup from pg_stat_user_tables where relname='t';

 relname n_live_tup n_dead_tup 
 t               91         11

vacuum (verbose ,analyze ) t;

INFO: vacuuming "public.t"
INFO: "t": removed 11 row versions in 1 pages
INFO: "t": found 11 removable, 91 nonremovable row versions in 1 out of 1 pages
描述: 0 dead row versions cannot be removed yet, oldest xmin: 993
There were 2 unused item pointers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.02 s.
INFO: analyzing "public.t"
INFO: "t": scanned 1 of 1 pages, containing 91 live rows and 0 dead rows; 91 rows in sample, 91 estimated total rows
VACUUM

postgres=# select relname,n_live_tup,n_dead_tup,last_vacuum,last_analyze from pg_stat_user_tables where relname='t';

relname n_live_tup n_dead_tup last_vacuum last_analyze
t 91 0 2018-12-19 10:33:13.155231+08 2018-12-19 10:33:13.157232+08

(1 行记录)
--不带表名的vacuum会回收统计系统中的所有的表,此时系统会有大量的io操作,故不要在数据库繁忙时操作
 vacuum (verbose ,analyze ) ;
 

-- 注意 vacuum full会锁表和索引,而且是“AccessExclusiveLock”级别的。其实vacuum full会重建整个表,这个的功能实现在cluster.c文件中,因为其行业相当于是一个cluster重建的一个变种

vacuum的功能

1.回收空间

    这个通常是大家最容易想起来的功能。回收空间,将dead tuple清理掉。但是已经分配的空间,一般不会释放掉。除非做vacuum full,但是需要exclusive lock。
一般不太建议,因为如果表最终还是会涨到这个高水位上,经常做vacuum full意义不是非常大。一般合理设置vacuum参数,进行常规vacuum也就够了。

2.冻结tuple的xid

  PG会在每条记录(tuple)的header中,存放xmin,xmax信息(增删改事务ID)。transactionID的最大值为2的32次,即无符整形来表示。当transactionID超过此最大值后,会循环使用。

这会带来一个问题:就是最新事务的transactionID会小于老事务的transactionID。如果这种情况发生后,PG就没有办法按transactionID来区分事务的先后,也没有办法实现MVCC了。
因此PG用vacuum后台进程,按一定的周期和算法触发vacuum动作,将过老的tuple的header中的事务ID进行冻结。冻结事务ID,即将事务ID设置为“2”(“0”表示无效事务ID;“1”表示bootstrap,
即初始化;“3”表示最小的事务ID)。PG认为被冻结的事务ID比任何事务都要老。这样就不会出现上面的这种情况了。

3.更新统计信息

    vacuum analyze时,会更新统计信息,让PG的planner能够算出更准确的执行计划。autovacuum_analyze_threshold和autovacuum_analyze_scale_factor参数可以控制analyze的触发的频率。

4.更新visibility map

在PG中,有一个visibility map用来标记那些page中是没有dead tuple的。这有两个好处,一是当vacuum进行scan时,直接可以跳过这些page。
二是进行index-only scan时,可以先检查下visibility map。这样减少fetch tuple时的可见性判断,从而减少IO操作,提高性能。
另外visibility map相对整个relation,还是小很多,可以cache到内存中。

自动vacuum配置
自动vacuum的执行直接由autovacuum参数值决定,默认值是on。
log_autovacuum_min_duration:默认值为-1,关闭vacuum的日志记录,配置为0表示记录autovacuum的所有log。参数设置为正整数表示对于在此时间内完成的vacuum操作不进行log记录,如果没能完成,则记录超出时间内的log。该参数对于了解对象执行vacuum操作的时间非常有用。
autovacuum_max_workers:最大的autovacuum进程的数量,默认值为3。参数大小的配置主要依据系统当前负载和资源。对于系统负载较重的情况,建议开启少量的进程为好,反之,空闲时间可以采用较大值的方式。
autovacuum_naptime:检查数据库的时间间隔。默认为1分钟。
autovacuum_vacuum_threshold:参数表示执行autovacuum操作之前,对单个表中记录执行DML操作的最少行数。达到该行数时自动激活autovacuum操作。该参数针对数据库中的所有表,还可以通过对单个表配置不同的值来改变相应表的autovacuum操作。默认值是50。
autovacuum_analyze_threshold:激活自动analyze操作的最小行数。默认值50。机制与上面相同。
autovacuum_vacuum_scale_factor:该参数采用百分比的方式设定阀值。默认值为20%,当DML涉及的数据量大于某个表的20%时,自动触发autovacuum操作。同样可以通过对单个表进行阀值设定。
autovacuum_analyze_scale_factor:机制与上面相同,到达阀值是自动激活analyze操作。同样可以通过对单个表进行阀值设定。
autovacuum_freeze_max_age:为防止事务ID的重置,在启用vacuum操作之前,表的pg_class .relfrozenxid字段的最大值,默认为200万。
autovacuum_vacuum_cost_delay:autovacuum进程的时间延迟限制,默认值是20ms。对于单个表同样适用。
autovacuum_vacuum_cost_limit:autovacuum进程的开销延迟限制,默认值是-1,表示不进行开销限制,系统将会直接依据vacuum_cost_limit参数管理vacuum的开销。对于单个表同样适用。
-

网友评论

登录后评论
0/500
评论
流浪的猫666
+ 关注