データベースに55 GBのSQLファイルを書き込もうとしています。毎回クラッシュが発生しました。ログを削除してクリーンアップ操作を実行してサーバーを実行しましたが、トランザクションは完了していません。後で書いていたすべてのテーブルを空にしましたが(バックアップがありました)、その後もSQLファイルに書き込もうとすると、一連の成功した挿入後にこのエラーが発生しました。ファイルを書き込めません。 "オフセット 106496 の pg_subtrans" /14C6": デバイスに余分なスペースがありません。
この問題を解決する方法はありますか?クリーンアップする必要があるPGSQL関連のログがありますか? pg_xlogを移動することが役に立つかもしれないことを読んだ。これを試してみるべきですか?
どんな助けでも大変感謝します。
ありがとうございます!
df -h
読みやすくするために、コメント出力形式を再指定しました。
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_zarkin-lv_root 574G 540G 4.3G 100% /
/dev/sda1 194M 35M 150M 19% /boot
tmpfs 5.9G 928K 5.9G 1% /dev/shm
/dev/mapper/smeidc0-smeisky0 7.2T 5.2T 2.0T 73% /smeidc/sky0
/dev/md0 7.2T 6.5T 400G 95% /smeidc/backup
ベストアンサー1
データベースに55 GBのSQLファイルを書き込もうとしています。 [...] デバイスに余分なスペースがありません。この問題を解決する方法はありますか?
いいえ。
ロードする前に、アプリケーションに十分な量のデータを提供する必要があります。
この回答が少し簡潔であることがわかっているので、以下に初心者レベルのヒントを追加してください。
私のディスクスペースはどこに行きましたか?
Postgres テーブルで使用されるディスク容量の合計は、次を含む物理モデルの結果です。
- テーブル行を含むテーブルブロック
- インデックスブロック(インデックス付きの場合)
- トランザクションログ(別名WALまたはxlog、しばらくすると消えます)
テーブル行の物理サイズは、データ型とデータ圧縮の程度によって異なります。約あります。行ごとに22バイトのオーバーヘッドがあるため、約100バイトの生の圧縮データがある場合、行は約122バイトを占めます。
インデックスの物理サイズは予測が難しく、インデックスフィールドとインデックスタイプによって異なります。
一括更新中にディスク使用量を減らすには?
ディスクのオーバーヘッドを最小限に抑えるには、PostgreSQLのドキュメントの公式パフォーマンスのヒントに従ってください。
一括更新後にディスク使用量を減らすには?
以下は、PostgreSQLデータベースのサイズを縮小するのに役立ついくつかのヒントです。
テーブル全体を消去したい場合は、SQLを参照してください。
DELETE
ファイルが常にクリーンアップされるわけではありません。使用TRUNCATE
DELETE
、テーブルの内容を完全に削除しないでください。テーブルを完全に消去できず、行の大きなサブセット(50%以上)を削除する必要がある場合は、次のコマンドを実行すると便利です。
VACUUM FULL
またはCLUSTER
DELETE 以降のコマンドは、テーブルを縮小するために使用されます。トランザクションログ(pg_xlogディレクトリ)に保持されるデータ量は、次のように制御できます。Postgresサーバーの設定
未使用のデータベース、テーブル、およびインデックスは、次のコマンドを使用して検出できます。システムビュー(pg_stat_database, pg_stat_user_tables, pg_stat_user_indexes)