手动执行VACUUM,无法清理表中的dead tuple

目录

环境

症状

问题原因

解决方案

环境

系统平台:N/A

版本:4.1.1

症状

  应用方反映业务量不大的情况下服务器负载较高,执行SQL的速度明显感觉缓慢。检查数据库TOP SQL,发现与表test有关,查看该表的统计值,live_tuple只有91966条,dead tuple为702346条。

  

highgo=# select n_live_tup,n_dead_tup from pg_stat_all_tables where relname = 'test';

 n_live_tup | n_dead_tup

------------+------------

    91966 |   702346

(1 row)

  手动对该表执行VACUUM同样无法回收dead tuple,报错如下:

highgo=# vacuum(verbose,analyze) test;

INFO:  00000: vacuuming "public.test"

INFO:  00000: index "index_test_content_id" now contains 146076 row versions in 698 pages

DETAIL:  0 index row versions were removed.

175 index pages have been deleted, 126 are currently reusable.

CPU 0.00s/0.00u sec elapsed 0.00 sec.

INFO:  00000: index "test_pkey" now contains 146076 row versions in 568 pages

DETAIL:  0 index row versions were removed.

77 index pages have been deleted, 68 are currently reusable.

CPU 0.00s/0.00u sec elapsed 0.00 sec.

INFO:  00000: "test": found 0 removable, 789485 nonremovable row versions in 10178 out of 10276 pages

DETAIL:  702346 dead row versions cannot be removed yet.

There were 59707 unused item pointers.

Skipped 0 pages due to buffer pins.

0 pages are entirely empty.

CPU 0.04s/0.15u sec elapsed 0.20 sec.

INFO:  00000: vacuuming "pg_toast.pg_toast_16737"

INFO:  00000: index "pg_toast_16737_index" now contains 0 row versions in 1 pages

DETAIL:  0 index row versions were removed.

0 index pages have been deleted, 0 are currently reusable.

CPU 0.00s/0.00u sec elapsed 0.13 sec.

INFO:  00000: "pg_toast_16737": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages

DETAIL:  0 dead row versions cannot be removed yet.

There were 0 unused item pointers.

Skipped 0 pages due to buffer pins.

0 pages are entirely empty.

CPU 0.00s/0.00u sec elapsed 0.59 sec.

INFO:  00000: analyzing "public.test"

INFO:  00000: "test": scanned 10276 of 10276 pages, containing 90959 live rows and 702346 dead rows; 30000 rows in sample, 90959 estimated total row

问题原因

 当我们开启一个事务后,为了实现多版本的控制,数据库会阻止未结束的长事务之后产生的所有dead tuple,即使与该事务无关的其他表也是如此。

- Live transactions performing a write operation in any table will prevent vacuuming dead rows

generated by commited transactions that started after first live transaction in any other table.

详细的解决方案请登录【瀚高技术支持平台】查看

https://support.highgo.com/#/index/docContent/35b88a720452d610

猜你喜欢

转载自blog.csdn.net/pg_hgdb/article/details/83500896