Full VACUUMしなきゃいけないことになっったので調査ついでに「VACUUM FULL」コマンドと「pg_repack」コマンドでロック時間がどれくらい違うかやってたみた。
pg_repack
感覚的な検証内容です
検証手順
1.DBを用意してtableを作る
create table hogehoge ( id integer primary key, val text );
2. データを入れる
INSERT INTO hogehoge(id, val) SELECT id,md5(clock_timestamp()::TEXT) AS val FROM generate_series(1,20000000) AS id;
3.データを消す
DELETE FROM hogehoge WHERE id <= 19999999;
4.テーブルのrelfilenodeを確認
SELECT relfilenode,relname FROM pg_class WHERE relname = 'hogehoge';
この番号のファイルがデータサイズになります
5.データサイズを確認する
ls -lh /var/lib/pgsql/9.6/data/base/16384/16494*
ここではいかのようになりました。
1GBのファイルサイズになりました。
-rw-------. 1 postgres postgres 1.0G Aug 7 02:36 /var/lib/pgsql/9.6/data/base/16384/16494 -rw-------. 1 postgres postgres 259M Aug 7 02:36 /var/lib/pgsql/9.6/data/base/16384/16494.1 -rw-------. 1 postgres postgres 344K Aug 7 02:36 /var/lib/pgsql/9.6/data/base/16384/16494_fsm -rw-------. 1 postgres postgres 24K Aug 7 02:36 /var/lib/pgsql/9.6/data/base/16384/16494_vm
これはDBの中身をほぼ消した状態ですがこれだけのサイズを確保しているということです。
(消す前も同じサイズかはやってみてください)
これをVACUUMして行きます。
VACUUM FULLを行った場合
# VACUUM (FULL,VERBOSE, ANALYZE) hogehoge; INFO: vacuuming "public.hogehoge" INFO: "hogehoge": found 10000000 removable, 1 nonremovable row versions in 166667 pages DETAIL: 0 dead row versions cannot be removed yet. CPU 0.75s/1.67u sec elapsed 17.41 sec. INFO: analyzing "public.hogehoge" INFO: "hogehoge": scanned 1 of 1 pages, containing 1 live rows and 0 dead rows; 1 rows in sample, 1 estimated total rows VACUUM
17秒かかりました。イコールロック時間が17秒ってことです。
pg_repackを使用した場合
$ time /usr/pgsql-9.6/bin/pg_repack --no-order --table hogehoge test INFO: repacking table "public.hogehoge" WARNING: canceling conflicted backends real 1m11.985s user 0m0.006s sys 0m0.009s
コマンド自体は71秒かかっています。
しかしこの時間全てでロックがかかっているということではありません。
正確には「WARNING: canceling conflicted backends」のログを出力されてから終わるまでです。
ここでは約7秒ほどでした。
比較
方法 | ロック時間 |
---|---|
VACUUM FULL | 17s |
pg_repack | 7s |
謳い文句の通りpg_repackが短いです。
今回のデータだからとかもろもろ要因はあるかもしれないですがとりあえず参考値程度にしといてください。
終わり