2

私は「ちょっとした」問題を抱えています。1 週間前、データベースがディスク容量いっぱいになりました。ディスク領域を解放しようとして、さまざまなテーブルの多くの行を削除しました。その後、完全な真空を実行しようとしましたが、完了しませんでした。

私が知りたいのは。バキュームの完全な完了を停止した場合、手動で削除する必要がある一時ファイルがディスクに残りますか? 現在、ディスク容量が 100% のデータベースがありますが、これは言うまでもなく大きな問題です。

ディスク領域を解放するためのヒントはありますか?

postgres 8.1.4 データベースで SUSE を実行しています。

4

2 に答える 2

5

初めに：

アップグレード

8.2、8.3、または 8.4 にアップグレードできない場合でも、少なくとも最新の 8.1 (現時点では 8.1.17 ですが、1 ～ 2 日で 8.1.18 になります) にアップグレードしてください。

2 番目: 何が問題なのかを診断します。

duツールを使用して、スペースがどこに移動したかを正確に診断します。スペースを占有しすぎているディレクトリは?

dfで合計使用容量を確認してから、PostgreSQL ディレクトリがどれくらいあるかを確認します。

最良のオプションは次のとおりです。

cd YOUR_PGDATA_DIR
du -sk *
cd base
du -sk *
cd LARGEST DIR FROM PREVIOUS COMMAND
du -sk * | sort -nr | head

これで、PGDATA 内のどのディレクトリがスペースを使用しているかがわかったので、それについて何かできることがあります。

ログまたは pg_temp の場合 - pg を再起動するか、ログを削除します (pg_clog と pg_xlog は一般的な意味でのログではありません。そこから何も削除しないでください!)。

それがベースディレクトリにある場合は、次のようになります。

ベース ディレクトリ内の数値ディレクトリは、データベースに関連しています。次の方法で確認できます。

select oid, datname from pg_database;

ほとんどのスペースを使用しているデータベースがわかっている場合は、それに接続し、どのファイルがほとんどのスペースを使用しているかを確認します。

ファイル名は、オプションの「.digits」サフィックスが付いた数値になります。このサフィックスは (今のところ) 無関係であり、次のコマンドを実行して、ファイルが正確に何を表しているかを確認できます。

select relname from pg_class  where relfilenode = <NUMBER_FROM_FILE_NAME>;

どのテーブル/インデックスがスペースの大部分を使用しているかがわかったら、それを VACUUM FULL するか、(はるかに良い)それらに対してCLUSTERコマンドを発行できます。

于 2009-09-04T11:48:08.327 に答える
2

問題の新しい接線では、クエリを使用して、データベース内で多くのスペースを使用しているものを見つけることができます。これは、TRUNCATE の候補を見つけて、削除された情報をクリーンアップするのに十分な作業スペースを再利用するのに役立ちます。

多くの行を削除しても、ディスク領域をチェックするのに十分な頻度で VACUUM を実行しないと、多くの場合、インデックスの肥大化と呼ばれる状態につながることに注意してください。これは、VACUUM FULL ではまったく役に立ちません。私が提案したクエリが、スペースの大部分が通常のテーブルではなくインデックスによって占められていることを示している場合、そこにいることがわかります。その問題から回復するには、すべてを再構築するためにテーブル自体と同じくらいの空きディスク領域を必要とする CLUSTER が必要です。

于 2009-09-04T23:08:51.960 に答える