4

現在、2つのインデックスと2億5000万のアクティブな行、およびほぼ同じ数（またはそれ以上）のデッド行を持つテーブルをクリーンアップしています。クライアントコンピューター（ラップトップ）からサーバーにコマンドVACCUMFULLANALYZEを発行しました。過去3〜4日ほどビジネスを続けています。やらなければいけないことがたくさんあるので、もうすぐ終わるのではないかと思います！

サーバーには、クアッドコードXeon 2.66 GHzプロセッサ、12 GBまたはRAM、およびRAID1構成の2x 10K rpm 146 GBSASHDに接続されたRAIDコントローラーがあります。SuseLinuxを実行しています。不思議なんだけど...

さて、まず、VACUUMポストマスタープロセスは1つのコアのみを使用しているようです。第二に、I/Oアイドル時間の比率に対するI/O書き込みが非常に高くないことです。第三に、呼び出しからprocinfo、VACUUMプロセスがほとんどの時間（88％）をI/0の待機に費やしていると推定できます。

では、RAIDコントローラーを過負荷にする（アイドル率に対するI / O書き込みを高くする）ために、スレッドを介してより多くのコアを利用しないのはなぜですか？I / O負荷が高くないのに、なぜI / Oを待機しているのですか？このすべてのパワー/リソースをすぐに利用できるのに、なぜ速くならないのでしょうか。VACUUMはマルチスレッド化できるし、マルチスレッド化する必要があるように思えます。特に、巨大なテーブルで動作していて、それが唯一動作している場合はそうです。

また、postgresql.confを構成してそのようなVACUUMをマルチスレッド化する方法はありますか？それを殺しても、部分的なクリーンアップの恩恵を受けることはできますか？そのテーブルで作業する必要があります。

[PostgreSQL8.1を使用しています]

再びThx

4

4 に答える 4

5

使用している PostgreSQL のバージョンはわかりません。8.0より前の可能性はありますか？

私はこれとまったく同じシナリオを持っていました。あなたのベストベスト:

  • 真空を殺す
  • pg_dump -t オプションでテーブルをバックアップする
  • テーブルを落とす
  • テーブルを復元する

8.x を使用している場合は、autovacuum オプションを確認してください。バキュームはシングル スレッドです。複数のスレッドを使用するためにできることは何もありません。

于 2009-01-11T23:39:54.870 に答える
4

簡単なヒント:

  • VACUUM FULL VERBOSE を実行して、何が起こっているかを確認してください。
  • VACUUM の前にすべてのインデックスを削除します。それらをバキュームするよりも再構築する方が高速です。VACUUM FULL では十分ではないため (特に 8.1 などの古い PosgreSQL では)、それらを再構築する必要もあります。
  • maintenance_work_mem を非常に高く設定します。
  • 新しい PostgreSQL を使用します。ところで、8.4 ではバキューム処理が大幅に改善されます。

VACUUM に代わる方法は、ダンプと復元です。

編集: 9.0 以降、VACUUM FULL はテーブル全体を書き換えます。ダンプ＋リストアと基本的には同じなのでREINDEXの実行は不要です。

于 2009-01-12T01:15:35.037 に答える
0

テーブルをロックし、バキュームの実行を妨げる可能性のある進行中のものはありませんか?

(とにかく、vacuum_cost_delayを使用して、vacuum が本番環境に影響を与えないようにすることをお勧めします。)

于 2009-01-24T00:49:47.473 に答える
0

古いVACUUM FULLは化石です。それもかなり遅いですし、後で REINDEX にたどり着きました。使用しないでください。本当にテーブルを最適化したい場合は、CLUSTER を使用するか、次のようにします。

ディスク容量が残っているとしましょう。これは、 dump&reload よりもはるかに高速です。

CREATE TABLE newtable AS SELECT * FROM oldtable;
CREATE INDEX bla ON newtable( ... );
ALTER TABLE oldtable RENAME TO archive;
ALTER TABLE newtable RENAME TO oldtable;

これは制約をコピーしないことに注意してください。CREATE TABLE LIKE ... を使用してそれらをコピーできます。

では、スレッドを介してより多くのコアを利用しないのはなぜですか

pg はこれをサポートしていません。

于 2011-05-04T16:05:29.067 に答える