web-dev-qa-db-ja.com

自動バキュームがオンになっている場合、PostgreSQLデータベースを手動でバキュームする必要がありますか？

大きなPostgreSQLデータベースを作成するソフトウェアを使用しています（100万行のテーブルがあります）。開発者は、定期的にVACUUMおよびANALYZEを実行する必要があると言っています。ただし、PostgreSQLデータベースのデフォルトはautovacuumがオンになっています。

掃除機をかける必要がありますか？メリットは何ですか？自動バキュームと手動バキュームの違いは何ですか

たとえば、Pgadmin3では、次のようになっています。
enter image description here

postgresqlmaintenancevacuum
15
kissgyorgy

私はETLに同意します。短い答えはありません。重要なのはサイズだけではありません-非常に大きなPostgreSQL OLTPデータベース（一部のテーブルが100.000.000行を含む））を高負荷で実行し、現在は自動バキュームのみに依存しています。

しかし、私には2つのことが重要だと思われます。

  • データベースに非常に明確に定義されたワークロードがあり、あなたが正確に何を知っているのでない限り、autovacuumは決してオフにすべきではないというコンセンサスがあるようですやっている。ただし、当然、追加のVACUUMやANALYZEを実行することもできます。

  • 追加のVACUUM実行を検討する前に、autovacuumがどのように機能するかを確認します。 pg_stat_user_tablesとpg_classをクエリすることで、自動バキュームのしきい値を超えているテーブルがあるかどうかを確認できます。私はこのようなクエリを別のスレッドに投稿しましたが、興味深いかもしれません： PostgreSQLの積極的な自動バキューム 。

    残念ながら、自動分析のしきい値について同様のチェックを行うのは簡単ではありません（つまり、現時点では不可能です）。ただし、自動分析はデフォルトで自動バキュームのかなり前に開始され、はるかに安価です。したがって、基本的にデータベースが自動バキュームに追いつくことができる場合、おそらく自動分析でも問題ありません。最後の自動分析日付は、pg_stat_user_tablesからも照会できます。

（最も優れた）PostgreSQLドキュメントの一部、私が参考にしたもの：

12
pygrac

Autovacuum は、何かを誤って設定しない限り、それをかなりカバーするはずです。他の回答はすでにそれをカバーしています。

manualVACUUM（さらに重要なのは手動ANALYZE）の明確に定義されたケースが1つあります：一時テーブル、それらはautovacuumデーモンによって考慮されません。私は引用します ここでCREATE TABLEのマニュアル ：

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

7
Erwin Brandstetter

それは多くの要因に依存するので、それに対する簡単な答えはありません。システムは遅いですか？自動バキュームは実際にこのテーブルに触れていますか？等.

この件に関するいくつかの優れたリンクを次に示します。

明確な決定を行うには、データベース自体の理解と、何が起こっているかについての詳細が必要です。

4
ETL

パフォーマンスの低下が見られない限り、手動で掃除機をかける必要はないと思います。ただし、バキュームと自動バキュームの設定を確認し、ニーズに合わせて調整することを強くお勧めします

現在の設定を確認するには、次のクエリを実行します。

SELECT *
FROM pg_settings 
WHERE name LIKE '%vacuum%'

ほとんどのフィールドは自明ですが、ここにそれらのドキュメントがあります： https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

あなたの目標は、ゴミを一貫して掃除するようにautovacuumを設定することですが、autovacuumを常に実行しないでください

最も重要な設定は次のとおりです。

  • autovacuum_vacuum_scale_factor-クリーンアップがトリガーされる前に無効になる可能性のあるタプルの割合を決定します。デフォルト値= 0.2
  • autovacuum_vacuum_threshold-クリーンアップがトリガーされる前のデッドタプルの最小数。デフォルト値= 50

しきい値は、小さいテーブルに対してクリーンアッププロセスが頻繁にトリガーされるのを防ぐのに役立ちます。

非常に大きなテーブルがない限り、デフォルト設定で問題ありません。簡単に言えば、たまたま100GBのテーブルがある場合、自動バキュームがトリガーされる前に、20GBのガベージを蓄積することになります。したがって、通常は倍率を低く設定することをお勧めします。どれだけ低いかを自分で判断する必要があります。現在のプロジェクトで0.05を使用しています

しきい値も増やすことができます。多くのアプリケーションには、頻繁に更新される2つのテーブルがあり、50タプルはそれほど多くありません。これを1000に増やしても問題はありませんが、もちろん、あなた自身のケースを検討する必要があります

自動バキュームを微調整して、いくつかのテーブルに異なる設定をすることもできます

ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

Scale_factorとしきい値を構成する場合は問題ありません。また、autovacuum_vacuum_cost_limitを増やすこともできます。これはデフォルトでvacuum_cost_limitに等しく、200に設定されています。これはバキュームの非常に重要な機能であり、すべてのリソースを使い果たして、アプリケーションは、バキュームプロセス中でもデータを操作できますが、デフォルト値が低すぎます。 1000に増やしても大幅な遅延は発生しませんが、真空プロセスがはるかに速く終了します。

もちろん、手動でバキュームを実行することもできます。最も単純なケースでは、DBに頻繁にアクセスしないときに、毎晩完全にクリーンアップする単純なcronジョブを使用できます。

お役に立てば幸いです。

1
Hasan Ammori