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

私は大きなPostgreSQLデータベース（その中に百万行を持つテーブルがある）と、開発者は、私がすべきと言うするソフトウェアを使用VACUUMしてANALYZE定期的に。ただし、PostgreSQLデータベースのデフォルトはautovacuumオンになっています。

まったく掃除機をかける/分析する必要がありますか？利点は何ですか？自動真空と手動真空の違いは何ですか

たとえば、Pgadmin3では、これがあります。

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

それでも、私にとって重要なことは2つあります。

• 自動バキュームがすべきことを、コンセンサスがあるようです決して、あなたのデータベースに非常によく定義されたワークロードを持っている、あなたは、あなたがやっている内容を正確に把握しない限り、オフにしないこと。しかし、当然、追加の実行VACUUMやANALYZE実行が可能です。

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

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

私が役に立つと思った（最も優れた）PostgreSQLドキュメントの一部：

• 定期的な掃除機
• 統計コレクター

Autovacuumは、設定を間違えない限り、かなりうまくカバーするはずです。他の答えはすでにそれをカバーしています。

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

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

それは多くの要因に依存するため、それに対する短い答えはありません。システムは遅いですか？自動真空は実際にこのテーブルに触れていますか？等

このテーマに関するいくつかの優れたリンクを以下に示します。

• PostgreSQLのパフォーマンスに関する考慮事項
• パフォーマンスの最適化（PostgreSQL wiki）
• VACUUM、ANALYZE、EXPLAIN、およびCOUNTの概要（同じソース）
• pg_statビューの解釈、pg_statビューについて

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

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

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

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を必要とするテーブルがある場合、autovacuumがトリガーされる前に20GBのガベージが蓄積されます。したがって、通常、スケール係数を低く設定することをお勧めします。自分で決定する必要がある低さ。現在のプロジェクトで0.05を使用しています

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

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

ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

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

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

お役に立てば幸いです！