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

8

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

さらに調査を行ったところ、実行後でも、多数のデッドタプルを持つ大きなテーブルがあることがわかりましたVACUUM。たとえば、このレスポンスのクエリから生成された統計の一部を次に示します。

-[ 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（または300Mの125Mではなく0に近い）にならないのですか？

ドキュメントの状態：

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または自動バキュームのいずれかが機能しています。

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

-[ 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

postgresql postgresql-9.3 vacuum

— jwadsack
ソース

0 dead row versions cannot be removed yet.死んだタプルの削除をブロックする長期実行トランザクションがないことを示します。

— Erwin Brandstetter 2014

10

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を増やすと役立ちます。

— ジャネス
ソース

「長期トランザクション」の例を教えてください。長時間実行されているデータベースクエリまたはINSERT/ IMPORTですか？または、接続のオープン/クローズよりも長い何かを意味しますか？

— jwadsack '09 / 09/25

4

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

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

アライメントの最適化されたテーブルが元のテーブルよりも大きいのはなぜですか？

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

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

詳細はこちら：

バキュームがディスクスペースをオペレーティングシステムに返す

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

— アーウィンブランドステッター
ソース

1

私の質問が明確でない場合は申し訳ありませんが、残りの死んだタプルについて尋ねていました。VACUUMなしでFULLはディスクのサイズが減らないことは知っています。それで問題ありません。私が最初にリンクした投稿で最初にリンクした投稿のため、大きなテーブルについて言及しました。行が削除または更新されない大きなテーブルがある場合、勝つ... 大きなテーブルは毎日交換されます。

— jwadsack '09 / 09/25