タグ付けされた質問 「vacuum」

私はPostgreSQLに積極的にデータベースを自動バキュームさせようとしています。現在、自動バキュームを次のように構成しています。 autovacuum_vacuum_cost_delay = 0＃コストベースのバキュームをオフにする autovacuum_vacuum_cost_limit = 10000＃最大値 autovacuum_vacuum_threshold = 50＃デフォルト値 autovacuum_vacuum_scale_factor = 0.2＃デフォルト値 自動バキュームは、データベースに負荷がかかっていないときにのみ作動することに気付きました。そのため、ライブタプルよりもはるかに多くのデッドタプルが存在する状況に陥ります。例については、添付のスクリーンショットを参照してください。テーブルの1つには23個のライブタプルがありますが、16845個のデッドタプルがバキュームを待っています。それは非常識です！ テスト実行が終了し、データベースサーバーがアイドル状態になると、自動バキュームが開始されます。これは、データベースが既に稼働しているため、デッドタプルの数が20％のライブタプル+ 50を超えるたびに自動バキュームを開始したいので、これは望ましくありません設定済み。サーバーがアイドル状態のときの自動バキュームは、私にとって役に立たない。なぜなら、実稼働サーバーは、サーバーが負荷がかかっている場合でも実行するために自動バキュームが必要な理由で、持続時間にわたって1000更新/秒に達することが予想されるためである。 不足しているものはありますか？サーバーの負荷が高いときに自動バキュームを実行するにはどうすればよいですか？ 更新 これはロックの問題でしょうか？問題の表は、挿入後トリガーを介して移入されるサマリー表です。これらのテーブルはSHARE ROW EXCLUSIVEモードでロックされ、同じ行への同時書き込みを防ぎます。

42 postgresql  performance  performance-testing  vacuum 

UbuntuでPostgreSQL 9.1を使用しています。スケジュールはVACUUM ANALYZEまだ推奨されていますか、それとも自動バキュームですべてのニーズに対応できますか？ 答えが「依存する」の場合： 大きなデータベースがあります（30 GiBの圧縮ダンプサイズ、200 GiBのデータディレクトリ） データベースにETLを実行し、週に300万行近くをインポートします 最も頻繁に変更されるテーブルはすべてマスターテーブルから継承され、マスターテーブルにはデータがありません（データは週ごとに分割されます） 時間ごとのロールアップを作成し、そこから毎日、毎週、毎月のレポートを作成します スケジュールVACUUM ANALYZEがレポートに影響しているので、私は尋ねています。5時間以上実行されますが、通常のデータベースインポートに影響を与えていたため、今週2回停止する必要がありました。check_postgresデータベースの大きな膨張を報告しないため、それは実際には問題ではありません。 ドキュメントから、autovacuumはトランザクションIDのラップアラウンドも処理する必要があります。質問が立っています：私はまだ必要VACUUM ANALYZEですか？

38 postgresql  etl  vacuum 

Autovacuumの構成設定を設定する方法の例を100万個見つけましたが、現在の構成を一覧表示する方法を見つけることができないようです。 Postgres 9.1は、私が最も興味を持っているバージョンです。

36 postgresql  postgresql-9.1  vacuum 

サーバー上のhdスペースの90％近くを占めるテーブルが1つあります。スペースを空けるために、いくつかの列をドロップすることにしました。しかし、スペースをOSに戻す必要があります。ただし、問題は、VACUUM FULLを実行し、テーブルのコピーを作成するための十分な空き領域がない場合にどうなるかわからないことです。 VACUUM FULLは使用すべきではないことを理解していますが、このシナリオでは最良の選択肢であると考えました。 任意のアイデアをいただければ幸いです。 PostgreSQL 9.0.6を使用しています

27 postgresql  delete  alter-table  database-size  vacuum 

VACUUM通常、特別な場合を除いて、オペレーティングシステムにディスク領域を返しません。 ドキュメントから： 標準形式でVACUUMは、テーブルとインデックス内の無効な行バージョンを削除し、将来の再利用に使用可能なスペースをマークします。ただし、テーブルの最後の1つ以上のページが完全に空になり、排他的なテーブルロックを簡単に取得できる特別な場合を除いて、オペレーティングシステムに領域を返しません。対照的に、VACUUM FULLデッドスペースのない完全に新しいバージョンのテーブルファイルを書き込むことにより、アクティブにテーブルを圧縮します。これにより、テーブルのサイズが最小になりますが、時間がかかる場合があります。また、操作が完了するまで、テーブルの新しいコピー用に追加のディスク領域が必要です。 問題は、このデータベースの状態をどのone or more pages at the end of a table become entirely freeように達成できるかということです。これはを介して行うことができますがVACUUM FULL、実装するのに十分なスペースがありません。他の可能性はありますか？

21 postgresql  postgresql-9.2  maintenance  disk-space  vacuum 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 3年前に移行され ました。 2015年のre：Inventのトークで、AWSは更新または削除の後だけでなく、挿入後にもバキュームを実行する必要があると述べました。講演の関連部分は次のとおりです。 http://www.youtube.com/watch?v=tZXp19q8RFo&t=16m2s ブロックが挿入のみを受信した場合でも、ブロックに対して実行する必要があるクリーンアップがあり、このクリーンアップは、ブロックが最初に選択されたとき（読み取りを遅くする）またはバキューム中に実行できます。これは本当ですか？もしそうなら、正確にどのようなクリーンアップを行う必要がありますか？

19 postgresql  postgresql-performance  vacuum 

VACUUMPostgreSQLのこれらのタイプの違いを誰かが説明できますか？ 私はドキュメントを読みましたが、それFULLはテーブルをロックしFREEZE、タプルを「フリーズ」するだけだと言っています。それは同じだと思います。私が間違っている？

18 postgresql  vacuum 

私は、さまざまなロールを持つテーブルを含む大きな（数百ギグの）データベースを管理しており、その中には数百万のレコードを保持しているものもあります。いくつかのテーブルは、多数の挿入と削除のみを受け取り、他のいくつかの挿入と多数の更新のみを受け取ります。 データベースは、16ギガバイトのRAMを備えたDebian 6.0 amd64システム上のPostgreSQL 8.4で実行されます。 質問は、テーブル上の自動バキュームプロセスであり、完了するまでに非常に長い時間（日）かかります。特定のバキュームコマンドにかかる時間を大まかに伝えて、キャンセルするかどうかを判断できるようにしたいと思います。また、postgresバキューム操作の進行状況インジケーターがある場合、それは本当に役立ちます。 編集： 私は防弾ソリューションを探していません。デッドタプルまたは必要なI / Oバイトの数についての大まかなヒントで十分です。いつVACUUM終了するかわからないのは本当に迷惑です。 pg_catalog.pg_stat_all_tablesデッドタプルの数の列があることを見てきました。そのためANALYZE、前にテーブルにアクセスする必要がある場合でも、見積もりを行うことができます。一方、autovacuum_vacuum_thresholdおよびautovacuum_vacuum_scale_factor設定だけではpostgres自身があることを証明知っているテーブル上の変化量について何かを、おそらくあまりにもDBAの手にそれを置きます。 実行するクエリがVACUUM VERBOSEわかりません。実行すると、テーブルだけでなくインデックスも処理されていることがわかります。

18 postgresql  vacuum 

私は大きなPostgreSQLデータベース（その中に百万行を持つテーブルがある）と、開発者は、私がすべきと言うするソフトウェアを使用VACUUMしてANALYZE定期的に。ただし、PostgreSQLデータベースのデフォルトはautovacuumオンになっています。 まったく掃除機をかける/分析する必要がありますか？利点は何ですか？自動真空と手動真空の違いは何ですか たとえば、Pgadmin3では、これがあります。

15 postgresql  maintenance  vacuum 

200 GBのサイズがデータで占められ、180 GBのサイズが6つのインデックスで占められているテーブルがあります。それは30％肥大化していますので、それによって占有されている不要なスペースを回収したいと思います。job_id_idxインデックスでクラスター化されます。 スペースを再利用するには、clusterコマンドまたはvacuum fullコマンドを使用する必要がありますか？ この2つのコマンドの違いは何ですか？ vacuum fullある列の順序はclusterコマンドと同じですか？ 両方のコマンドでインデックスが再作成されますか？ 私の場合、どちらが速くなりますか？ PostgreSQLデータベースのバージョンは9.1です

13 postgresql  postgresql-9.1  clustered-index  vacuum 

私は、2億4000万行の非常に頻繁に更新されるテーブルを持っています（そして成長しています）。3時間ごとに150万行が挿入され、150万行が削除されます。クラスターをSSDに移動すると、この一括挿入（コピーを使用）時間は22分から2.3分に短縮されました。削除時間も改善されました。この一括更新は2時間ごとまたは1時間ごとに行う予定です。 現在のパフォーマンス（SSD後）は、より頻繁な更新と互換性がありますが、書き込みの増幅と組み合わされたNANDの耐久性の限界によるSSDの死に関するいくつかの恐ろしい話を読みました。SSDは高価なので、可能な限り将来的にその死を押し上げたいと思います。したがって、私の質問：削除とその後のバキュームでディスクファイルは実際にどうなりますか？私は2つのディスク書き込みがあると思います。1つは行を削除済みとしてマークし、もう1つはバキュームして上書き可能としてマークします。削除とバキュームを行う代わりに、一括挿入/削除のたびにテーブルを作成および削除するテーブルをパーティション分割すると、SSDの摩耗を最小限に抑えることができますか？

13 postgresql  partitioning  delete  storage  vacuum 

場合によっては、大量のを作成した後update、insertまたはdeleteテーブルからVACUUM FULL ANALYZE、DBが肥大化していないことを確認するためにを開始しました。本番データベースでこれを行うと、長期間テーブルをブロックすることができたため、これは良いアイデアではなかったことがわかりました。それで、私はプロセスをキャンセルしました、多分ちょうどVACUUM（完全ではない）試みたか、AUTOVACUUMそれができることは何でも後でやらせ​​ます。 問題は、VACUUMまたはAUTOVACUUMを「途中」で停止すると、すでに実行されたすべての処理が失われるのですか？ たとえば、VACUUMすでに100万のデッド行が見つかって停止した場合、この情報はすべて失われますか？VACUUMは完全にトランザクション的な方法で動作しますか（非常に多くのPostgreSQLプロセスのように、「すべてまたは何もない」）？ すべての作業を失うことなくVACUUMを安全に中断できる場合、vacuum作業を段階的に行う方法はありますか？[100 ms動作し、停止し、10 ms待機して、残りの世界をブロックしないようにします...]。autovacuumパラメータを調整することでこれの一部を実行できることはわかっていますが、これをプログラムで制御できること、特定の時間/特定の条件下でそれを実行できるようにすることについて考えています。 注：プロセスを停止/キャンセル/強制終了するとは、次のことを意味します。 pgAdminを使用している場合は、[クエリのキャンセル]ボタンを押します。 プログラムで作業する場合は、pg_cancel_backend（）を呼び出します。 どちらも同等だと思います。シェル/システムレベルのkillコマンドは使用していません。

13 postgresql  vacuum  maintenance  autovacuum 

WindowsではPostgres 9.2を使用して低頻度の時系列データを保存しています。毎秒約2000行を毎秒24時間、週7日、ダウンタイムなしで挿入しています。あるDELETE日の固定数にテーブルの長さを保つためにテーブルの上におき、10分ほどにこれが実行されます。これはかなり安定した9億行になります。（興味のある方のために、SELECT、INSERT、DELETEすべてのパフォーマンスです）。 そのためDELETE、行を削除してもディスク領域は解放されません。そのためVACUUMに実行する必要があります。 私はしました照会pg_stat_user_tablesとVACUUM、これまで実行していないように見えます。 さまざまなドキュメントから理解できること（http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html）： 自動バキュームがオンになっているようで、他のテーブルで実行されています。 auto-vacuumは実行されませんFULL。また、テーブルの排他ロックは必要ありません。 自動バキュームが実行されていない理由はありますか？これは純粋にテーブルが常にビジーであるためですか？ そして、この場合はVACUUM毎回実行する価値がありますDELETE（10分ごとに実行されます）？ 編集： 以下のSOリンクからSQLを使用してクエリを実行します。 -[ RECORD 2 ]---+--------------------------- schemaname | stats relname | statistic_values_by_sec last_vacuum | last_autovacuum | n_tup | 932,315,264 dead_tup | 940,727,818 av_threshold | 186,463,103 expect_av | * 生の出力： -[ RECORD 3 ]-----+--------------------------- relid | 501908 schemaname | stats relname | …

11 postgresql  vacuum 

シリアル化されたJavaオブジェクトを格納するテーブルを大幅に更新/アクセスしました。これらは2〜3時間テーブルに表示され（その期間中にも更新されます）、その後削除されます。テーブルのサイズは約300MBです。私はそれが非常に、非常に頻繁にVACUUMされていることを発見しました、そしてそれを変えることfillfactorは助けになるのだろうか？

10 postgresql  configuration  nosql  vacuum  fill-factor 

私はいじくり回していて、テーブルから行をingすることで、後で行う必要のある作業が減るようVACUUMな予期しない動作に気づきました。SELECTVACUUM テストデータ 注：自動バキュームは無効になっています CREATE TABLE numbers (num bigint); ALTER TABLE numbers SET ( autovacuum_enabled = 'f', toast.autovacuum_enabled = 'f' ); INSERT INTO numbers SELECT generate_series(1, 5000); 試験1 次に、すべての行に対して更新を実行します。 UPDATE numbers SET num = 0; そして走るVACUUM (VERBOSE) numbers;と、 INFO: vacuuming "public.numbers" INFO: "numbers": removed 5000 row versions in 23 pages INFO: …

9 postgresql  select  vacuum  postgresql-11