[經驗分享] PostgreSQL碎片空間回收---vacuum

一般來講，PG表中的數據在刪除后會被標記為dead，除非進行自動的autovacuum或者是手動的vacuum，否則數據塊不會被回收，直觀的看來就是表的體積大，操作系統里表的文件臃腫不減。

下面我們來做一個大表清空數據后的信息統計和碎片回收實驗：

一張2 千萬數據的表：
music=# select count(*) from test;
  count  
---------
22000005
(1 行記錄)

容量大概有700MB：
music=# select pg_size_pretty(pg_relation_size('test'));
-[ RECORD 1 ]--+-------
pg_size_pretty | 691 MB

清除表中所有數據：
music=# delete from test;
DELETE 22000005




再確認一下表的體積：
music=# select pg_size_pretty(pg_relation_size('test'));
-[ RECORD 1 ]--+-------
pg_size_pretty | 691 MB

紋絲不動...


查看表的狀態：
music=# select * from pg_stat_user_tables where relname = 'test';
-[ RECORD 1 ]-------+------------------------------
relid               | 16391
schemaname          | public
relname             | test
seq_scan            | 11
seq_tup_read        | 52000055
idx_scan            |
idx_tup_fetch       |
n_tup_ins           | 56929554
n_tup_upd           | 0
n_tup_del           | 0
n_tup_hot_upd       | 0
n_live_tup          | 22000005
n_dead_tup          | 34929554
n_mod_since_analyze | 20000000
last_vacuum         |
last_autovacuum     |
last_analyze        |
last_autoanalyze    | 2015-07-30 13:21:36.385515+08
vacuum_count        | 0
autovacuum_count    | 0
analyze_count       | 0
autoanalyze_count   | 1


從輸出結果上看，此表仍然占用了大部分 ”空閑“ 數據塊。

n_live_tup的數量是當前表的數據量。
n_dead_tup的數據量是未回收的空間。
該表之前做過其他的測試，清理過數據，因此dead tuple比2千萬多。


查看磁盤空間：
[iyunv@dbserver music]# df -h
文件系統              容量  已用 可用 已用% 掛載點
/dev/mapper/VolGroup00-LogVol00
                       26G   20G  3.9G  84% /
/dev/sda1              99M   21M   73M  23% /boot
tmpfs                 1.3G  248M  1.1G  19% /dev/shm
none                  1.3G  104K  1.3G   1% /var/lib/xenstored



我們進行一下手工的清理：

music=# vacuum test;
VACUUM


可以看到有相應的后台進程啟動：

[iyunv@dbserver music]# ps -ef|grep VACUUM
postgres  6649  3540 13 13:55 ?        00:00:05 postgres: postgres music [local] VACUUM                 
root      6662  5515  0 13:55 pts/1    00:00:00 grep VACUUM
[iyunv@dbserver music]#


再次查看一下表的狀態，發現n_tup_del變成了剛才表的數量，活的和死的tuple都已成為0，下面的信息可以看到分析、自動清理和手動清理的時間。（系統為自己測試環境，時間不是北京時間，但是可以判斷先后順序）

music=# select * from pg_stat_user_tables where relname = 'test';
-[ RECORD 1 ]-------+------------------------------
relid               | 16391
schemaname          | public
relname             | test
seq_scan            | 12
seq_tup_read        | 74000060
idx_scan            |
idx_tup_fetch       |
n_tup_ins           | 56929554
n_tup_upd           | 0
n_tup_del           | 22000005
n_tup_hot_upd       | 0
n_live_tup          | 0
n_dead_tup          | 0
n_mod_since_analyze | 0
last_vacuum         | 2015-07-30 13:56:16.714987+08
last_autovacuum     | 2015-07-30 13:47:05.532724+08
last_analyze        |
last_autoanalyze    | 2015-07-30 13:56:36.112974+08
vacuum_count        | 1
autovacuum_count    | 1
analyze_count       | 0
autoanalyze_count   | 3


n_dead_tup和n_live_tup變成了0，空間已被回收。








查看一下表的體積：
music=# select pg_size_pretty(pg_relation_size('test'));
-[ RECORD 1 ]--+--------
pg_size_pretty | 0 bytes



查看磁盤空間：
[iyunv@dbserver music]# df -h
文件系統              容量  已用 可用 已用% 掛載點
/dev/mapper/VolGroup00-LogVol00
                       26G   20G  4.8G  81% /
/dev/sda1              99M   21M   73M  23% /boot
tmpfs                 1.3G  248M  1.1G  19% /dev/shm
none                  1.3G  104K  1.3G   1% /var/lib/xenstored　　




可以看到系統空間已下降。

OK~