web-dev-qa-db-ja.com

なぜVACUUM ANALYZEはすべての死んだタプルをクリアしないのですか？

「手動」を実行しますVACUUM ANALYZE VERBOSEメジャーテーブルを実行した後、いくつかの大きなテーブルでDELETE/INSERTそれらの変更。これは問題なく機能しているように見えますが、テーブルのVACUUMジョブが数時間実行される場合があります（同様の問題と理由については この投稿 を参照してください）。

さらに調査を行ったところ、VACUUMを実行した後でも、多数の無効なタプルを持つ大きなテーブルがあることがわかりました。たとえば、以下は this response のクエリから生成された統計の一部です。

-[ RECORD 50 ]--+---------------------------
relname         | example_a
last_vacuum     | 2014-09-23 01:43
last_autovacuum | 2014-08-01 01:19
n_tup           |    199,169,568
dead_tup        |    111,048,906
av_threshold    |     39,833,964
expect_av       | *
-[ RECORD 51 ]--+---------------------------
relname         | example_b
last_vacuum     | 2014-09-23 01:48
last_autovacuum | 2014-08-30 12:40
n_tup           |    216,596,624
dead_tup        |    117,224,220
av_threshold    |     43,319,375
expect_av       | *
-[ RECORD 52 ]--+---------------------------
relname         | example_c
last_vacuum     | 2014-09-23 01:55
last_autovacuum | 2014-09-23 18:25
n_tup           |    309,831,136
dead_tup        |    125,047,233
av_threshold    |     61,966,277
expect_av       | *

最後のフィールドは、これら（およびほとんどのテーブル）が自動バキュームのしきい値を満たすことを示しています。ただし、VACUUM ANALYZE VEBOSEこれらの各テーブルで、無効なタプルカウントを0（または0に近い、300Mの125Mではない）にしないでください。

documentation の状態：

VACUUMは、死んだタプルによって占有されているストレージを再利用します。

これは、VACUUMが機能していないことを意味しますか？

[〜＃〜]更新[〜＃〜]

返信のリクエストごとに、VERBOSEジョブからのログがいくつかあります。

INFO:  vacuuming "public.example_1"
INFO:  scanned index "idx_example_1_on_gp_id_and_dd_id" to remove 378386 row versions
DETAIL:  CPU 1.83s/3.42u sec elapsed 23.01 sec.
INFO:  scanned index "index_example_1_on_q_id" to remove 378386 row versions
DETAIL:  CPU 2.10s/3.91u sec elapsed 18.92 sec.
INFO:  "example_1": removed 378386 row versions in 7085 pages
DETAIL:  CPU 0.09s/0.05u sec elapsed 0.19 sec.
INFO:  index "idx_example_1_on_gp_id_and_dd_id" now contains 30347438 row versions in 291065 pages
DETAIL:  378386 index row versions were removed.
165587 index pages have been deleted, 164287 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  index "index_example_1_on_q_id" now contains 30347438 row versions in 333287 pages
DETAIL:  378386 index row versions were removed.
152773 index pages have been deleted, 152757 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "example_1": found 1773 removable, 401984 nonremovable row versions in 14438 out of 1493006 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 10567 unused item pointers.
0 pages are entirely empty.
CPU 4.26s/7.51u sec elapsed 46.10 sec.
INFO:  vacuuming "pg_toast.pg_toast_17917"
INFO:  index "pg_toast_17917_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.00 sec.
INFO:  "pg_toast_17917": 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.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  analyzing "public.example_1"
INFO:  "example_1": scanned 30000 of 1493006 pages, containing 611502 live rows and 0 dead rows; 30000 rows in sample, 40563141 estimated total rows

この表では、統計に0個の無効なタプルが表示されます。ほとんどのテーブルは今朝ははるかに低いデッドタプルなので、VACUUMまたはautovacuumのいずれかが機能しています。

何も出力せず、まだ無効なタプルを表示するテーブルがいくつかあります。

-[ RECORD 49 ]--+---------------------------
relname         | example_2
last_vacuum     | 2014-09-23 02:23
last_autovacuum | 2014-09-02 14:30
n_tup           |    117,914,944
dead_tup        |     34,507,388
av_threshold    |     23,583,039
expect_av       | *

インデックスが何度も何度もチェックされるログで数回見ました。これは、実行時間の長いVACUUMジョブに対応しているようです。なぜだろう？これは単にレコードのロックを回避しているだけですか（このジョブの実行中に書き込みが発生したとは思いません）。

INFO:  vacuuming "public.example_2"
...
INFO:  scanned index "index_example_2_on_gsg_id_and_dd_id" to remove 2795959 row versions
DETAIL:  CPU 3.88s/16.54u sec elapsed 23.09 sec.
INFO:  scanned index "index_example_2_on_q_id" to remove 2795959 row versions
DETAIL:  CPU 6.74s/21.13u sec elapsed 84.64 sec.
INFO:  "example_2": removed 2795959 row versions in 48214 pages
DETAIL:  CPU 0.71s/0.32u sec elapsed 33.65 sec.
INFO:  scanned index "index_example_2_on_gsg_id_and_dd_id" to remove 2591011 row versions
DETAIL:  CPU 2.84s/16.11u sec elapsed 19.28 sec.
INFO:  scanned index "index_example_2_on_q_id" to remove 2591011 row versions
DETAIL:  CPU 5.46s/22.70u sec elapsed 130.57 sec.
INFO:  "example_2": removed 2591011 row versions in 45539 pages
DETAIL:  CPU 0.67s/0.38u sec elapsed 15.16 sec.
INFO:  index "index_example_2_on_gsg_id_and_dd_id" now contains 123807784 row versions in 1560915 pages
DETAIL:  108836958 index row versions were removed.
1100790 index pages have been deleted, 718471 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.25 sec.
INFO:  index "index_example_2_on_q_id" now contains 123807784 row versions in 1886087 pages
DETAIL:  110336259 index row versions were removed.
1058063 index pages have been deleted, 266983 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.07 sec.
INFO:  "example_2": found 124808 removable, 1355901 nonremovable row versions in 2086343 out of 6966379 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 7858495 unused item pointers.
0 pages are entirely empty.
CPU 595.49s/2130.13u sec elapsed 5656.34 sec.
INFO:  vacuuming "pg_toast.pg_toast_18079"
INFO:  index "pg_toast_18079_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.00 sec.
INFO:  "pg_toast_18079": 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.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  analyzing "public.example_2"
INFO:  "example_2": scanned 30000 of 6966379 pages, containing 528443 live rows and 522 dead rows; 30000 rows in sample, 152953760 estimated total rows
postgresqlpostgresql-9.3vacuum
8
jwadsack

VACUUMは、長いデッド、つまりすべての可能な用途に対してデッドであるデッドタプルのみを削除できます。トランザクションの寿命が長い場合、最近死んだタプルが削除されない可能性があります。

これは、長期間有効なトランザクションが削除を妨げていた状況の例です。

INFO:  "pgbench_accounts": found 0 removable, 2999042 nonremovable row versions in 49181 out of 163935 pages
DETAIL:  2999000 dead row versions cannot be removed yet.

これは実際には長期間有効なトランザクションではなく、長期間有効なスナップショットです。確かに、実行時間の長いselectまたはinsertステートメントはそれを行います。読み取りコミットよりも高い分離レベルの場合、トランザクション全体が停止するまでスナップショットを保持するため、反復可能な読み取りトランザクションを開いて、コミットせずに休暇に入ると、問題が発生します。準備済みトランザクションを切断することもできます（準備済みトランザクションが何であるかわからない場合は、おそらくそれらを使用していません）。

表示されている例は問題を示しているわけではありませんが、問題はそれまでに解決されたとも言えます。これが繰り返し発生する問題である場合は、VACUUM VERBOSEステートメントの出力のロギングを開始して、問題が発生している期間をカバーする情報を見つけられるようにする必要があります。

インデックスに対する複数のパスは、maintenance_work_mem設定が原因です。インデックスの各パスでメモリの6バイトごとに1つのタプルしか削除できません。それ以上削除する必要がある場合は、複数のパスを作成する必要があります。したがって、maintenance_work_memを増やすと役立ちます。

10
jjanes

物理テーブルのサイズは通常、（テーブルの末尾からのリムーバブルページの日和見主義的プルーニングを除いて）VACUUM（またはVACUUM ANALYZE）を実行しても削減されません。実際にテーブルを縮小するには、 VACUUM FULL を実行する必要があります。

これは関連する回答からの引用であり、詳細が含まれています。

ドキュメントごと （実際には見積もりの​​下数行）：

プレーンVACUUM（FULLなし）は、単にスペースを再利用して、再利用できるようにします。この形式のコマンドは、排他ロックが取得されないため、テーブルの通常の読み取りおよび書き込みと並行して動作できます。ただし、余分なスペースはオペレーティングシステムに返されません（ほとんどの場合）。

詳細はこちら：

pg_repack に興味があります。これは、排他ロックなしでVACUUM FULLと同じことができます。

4
Erwin Brandstetter