1. ホーム /
  2. VACUUM

VACUUM

VACUUM処理が阻害されるケースとその原因・検知・対策

この記事のポイント

VACUUM コマンドや 自動VACUUM は成功するのだけれども（コマンド応答にもログにも ERROR などは出ないけれども）、実際にはデッドタプルが回収されない状況が発生することがあります。
VACUUMが期待通りに動作しない場合、以下を確認することで原因特定が可能です。

  • ログに「are dead but not yet removable」が出ているか(*)
  • ログの「removable cutoff / oldest xmin」の数字が進んでいないか(*)
  • 以下のビューを確認する(ストリーミングレプリケーション環境の場合はスタンバイ側も)
    • pg_stat_activity
    • pg_replication_slots
    • pg_prepared_xacts

主な原因は以下の3つです。

  1. ロングトランザクション
  2. レプリケーションスロット
  3. プリペアドトランザクション

対策の本質は 「oldest xminを固定している要因を解消すること」 です。
(*) log_autovacuum_min_duration パラメータを0や正の数で設定して自動VACUUM実行結果をログに出力する必要があります。

続きを読む

pg_repack (オンラインテーブル再編成ツール)

pg_repack は PostgreSQL のテーブルをオンラインで再編成できるツールです。本記事では pg_repackについて紹介します。

良く知られている通り、PostgreSQL は追記型アーキテクチャを採用しています。UPDATE や DELETE をしても旧データを格納した行はしばらく物理ファイル上に残り、これを VACUUM コマンドや自動 VACUUM で整理して、その領域を再利用可能にする仕組みとなっています。何らかの理由でこれらの手動・自動の VACUUM 処理が実行されなかった場合には、データ格納に使われない不要領域が増加し、性能劣化の原因となります。そのような場合には、CLUSTER コマンドや VACUUM FULL コマンドを使って、テーブルの再編成をするのですが、これらのコマンドは強いロックを取得するため、サービス中の適用が難しいという課題がありました。

pg_repack は CLUSTER または VACUUM FULL と同様に不要領域の削除や行の並び替えることができますが、処理中に強いロックをごく短時間しか取得しないため、サービス中にも実施が可能となります。

続きを読む