PG表膨胀及对策

PG表膨胀及对策

检查表膨胀

方法一 查询pg_stat_all_tables系统表

SELECT

    schemaname||'.'||relname,

    n_dead_tup,

    n_live_tup,

    round(n_dead_tup * 100 / (n_live_tup + n_dead_tup),2) AS dead_tup_ratio

FROM

    pg_stat_all_tables

WHERE

    n_dead_tup >= 10000

ORDER BY dead_tup_ratio DESC

LIMIT 10;

 

方法2 使用pg_bloat_check工具

 `pg_bloat_check`会进行全表扫描,比`pg_stat_all_tables`准确,但比较慢对系统性能冲击也较大,不建议作为常规工具使用。

 

 

以上方法包含了对索引膨胀的检查。但需要注意的是,表中不能被回收的dead tuple在索引页里是作为正常tuple而不是dead tuple记录的。考虑到这一点,索引的实际膨胀要乘以对应表的膨胀率。

 

预防表膨胀

  1. 调整autovacuum相关参数,加快垃圾回收速度

对于写入频繁的系统,默认的autovacuum_vacuum_cost_limit参数值可能过小,尤其在SSD机器上,可以适当调大。

autovacuum_vacuum_cost_limit = 4000

  1. 监视并处理以下可能导致dead元组无法被回收的状况
  1. 长事务
  2. 未决事务
  3. 断开的复制槽
  1. 强制回收

设置old_snapshot_threshold参数,强制删除为过老的事务快照保留的dead元组。这会导致长事务读取已被删除tuple时出错。

old_snapshot_threshold = 12h

old_snapshot_threshold不会影响更新事务和隔离级别为RR只读事务。old_snapshot_threshold参数也不能在线修改,如果已经设置了old_snapshot_threshold但又需要运行更长的RR只读事务或单个大的只读SQL,可以临时在备机上设置max_standby_streaming_delay = -1,然后在备机执行长事务(会带来主备延迟)

  1. 杀死长事务

设置可以部分避免长事务的参数

idle_in_transaction_session_timeout = 60s

lock_timeout = 70s

 

 

 

猜你喜欢

转载自blog.csdn.net/weixin_42767321/article/details/86141434