web-dev-qa-db-ja.com

通常のVACUUM ANALYZEは9.1でもまだ推奨されていますか？

UbuntuでPostgreSQL 9.1を使用しています。スケジュールされたVACUUM ANALYZEは引き続き推奨されますか、それともすべてのニーズを処理するのに十分な自動バキュームですか？

答えが「依存する」である場合、次のようになります。

  • 大量のデータベースがあります（30 GiB圧縮ダンプサイズ、200 GiBデータディレクトリ））
  • 私はデータベースにETLを行い、週に300万行近くインポートします
  • 最も頻繁に変更されるテーブルはすべてマスターテーブルから継承され、マスターテーブルにはデータがありません（データは週ごとに分割されます）
  • 時間ごとのロールアップを作成し、そこから、毎日、毎週、毎月のレポートを作成します

スケジュールされたVACUUM ANALYZEが私のレポートに影響を与えているので、お願いします。それは5時間以上実行され、定期的なデータベースのインポートに影響を与えていたため、今週2回は強制終了しました。 check_postgresはデータベースの大きな膨張を報告しないため、それは実際には問題ではありません。

ドキュメントから、autovacuumはトランザクションIDのラップアラウンドも処理する必要があります。問題はまだ残っています。それでもVACUUM ANALYZEは必要ですか？

postgresqletlvacuum
38
François Beausoleil

VACUUMは、非一時テーブルの更新または削除された行でのみ必要です。明らかに多くのINSERTを実行していますが、多くのUPDATEまたはDELETEを実行していることも説明からは明らかではありません。

これらの操作は、pg_stat_all_tablesビュー、特にn_tup_upd列とn_tup_del列で追跡できます。また、さらに重要なこととして、バキュームする必要がある行数をテーブルごとに示すn_dead_tup列があります。 （統計収集に関連する関数とビューについては、ドキュメントの Monitoring statistics を参照してください）。

この場合の考えられる戦略は、スケジュールされたVACUUMを抑制し、このビューを監視し、n_dead_tupが大幅に増加しているテーブルを確認することです。次に、これらのテーブルにのみ積極的なVACUUMを適用します。行が削除または更新されない大きなテーブルがあり、積極的なVACUUMが本当に必要なのは、小さなテーブルの場合だけです。

ただし、オプティマイザが常に最新の統計を取得できるようにANALYZEを実行し続けます。

32
Daniel Vérité

あなたの質問には、autovacuumが対応しないものは何もありません。それはあなたの執筆活動のパターンに大きく依存します。 1週間あたり300万new行について言及していますが、INSERT（またはCOPY）は通常、テーブルとインデックスの膨張を作成しません。 （autovacuumは 列統計 、 可視性マップ といくつかのマイナージョブのみを処理する必要があります）。 UPDATEとDELETEは、特にランダムな行を対象とする場合に、テーブルとインデックスの膨張の主な原因です。あなたの質問にはそれは見当たりません。

autovacuumは長い道のりを歩んでき、Postgres 9.1以降で素晴らしい仕事をしています。 autovacuum settings を見てみましょう。バキューム処理が作業負荷に干渉する傾向がある場合は、 "コストベースのバキューム遅延" も確認してください。手動バキューム処理はまれな例外です。

ランダムなUPDATEsがたくさんある場合は、 FILLFACTOR を100未満に設定して、HOT更新をすぐに許可し、VACUUMの必要性を減らすことができます。 HOTアップデートの詳細：

また、一時テーブルには手動のVACUUMとANALYZEが必要であることにも注意してください。私は引用します CREATE TABLEのマニュアル ：

autovacuumデーモン はアクセスできないため、一時テーブルをバキュームまたは分析できません。このため、セッションSQLコマンドを介して適切なバキュームおよび分析操作を実行する必要があります。たとえば、一時テーブルが複雑なクエリで使用される場合、一時テーブルにデータが入力された後にANALYZEを実行するのが賢明です。

25
Erwin Brandstetter

データベース全体で実行するのではなく、自動機能を使用するのが最善であることに同意しますが、ほとんどの場合、テーブルごとのチューニングが必要です。

真空と分析を結びつけるpostgresの設計の選択に完全に同意しません。多くの挿入/更新を実行するが削除がほとんど行われないデータベースが分析を実行せず、パフォーマンスが低下し始めるいくつかの例を見てきました。

解決策は、頻繁に使用され、大きなクエリの対象となるテーブルに移動し、それらのテーブルの自動分析設定を、1日おきまたは1日おきに分析される場所まで設定することです。

自動掃除機タブのGUIでテーブルごとの設定にアクセスすると、掃除機とは独立して設定できる分析設定が表示されます。

設定はreloptionsテーブルに格納され、クエリで確認できます

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

積極的な分析のサンプル値は

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

テーブルが最後に自動分析されたクエリを取得した時間を確認するには

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;
6
MvcCmsJon