Q&A
対象のディレクトリに「.backup 」のファイルはありませんので、違います。
実現したいこと
「/var/lib/pgsql/data/base/数字５桁のディレクトリ」の中を見ると、「数字八桁のファイル」や「数字八桁_fsm」や「数字八桁_vm」があります。このディレクトリの削除や容量低減方法があれば教えてください。
発生している問題・分からないこと
「/var/lib/pgsql/data/base/数字五桁のディレクトリ」が40GBほどに肥大化しています。
postgreSQLからのdumpデータは800MB程度でなのでかなり容量が乖離しています。
該当のソースコード
特になし
試したこと・調べたこと
- teratailやGoogle等で検索した
- ソースコードを自分なりに変更した
- 知人に聞いた
- その他
VACUUM FULL;
上記の詳細・結果
数字八桁のファイル」や「数字八桁_fsm」や「数字八桁_vm」の削除、容量削減についての記事がない。
VACUUM FULLをしたが変化なし。
補足
特になし
回答3件
0
自己解決
回答して下さった皆様、どうもありがとうございます。
dataディレクトリを削除してinitしなおしてリストアしました。
投稿2024/09/15 14:56
総合スコア18
0
投稿2024/09/14 13:32
総合スコア1681
0
恐らく、不要領域の解放が出来ていないのでサイズに差があると思います。
オンラインサービスなど停止が許されない環境ではないのであれば、
時間が掛かる処理ですがVACUUM FULLをやれば、サイズは小さくなると思います。
投稿2024/09/14 09:02
総合スコア453
回答ありがとうございます。下記試してみましたが解決できませんでした。
VACUUM FULL;
Updated Rows 0
Query VACUUM FULL
Start time Sat Sep 14 18:19:07 JST 2024
Finish time Sat Sep 14 18:44:37 JST 2024
サーバーで「/var/lib/pgsql/data/base/数字５桁のディレクトリ」の容量を確認しましたが何も変化はございませんでした。
`VACUUM FULL`の後に`ANALYZE`を実行しても変わらないでしょうか？
やってみましたが、変わりませんでした。
Updated Rows 0
Query VACUUM verbose analyze
Start time Sat Sep 14 22:14:26 JST 2024
Finish time Sat Sep 14 22:33:30 JST 2024
サーバー側でdu で確認しても何も変化ありません
どのテーブルのサイズが大きいか等はあたりは付いているのでしょうか？
もしついていないようでしたら、下記の記事で使えるクエリがいくつかあるので
参考にしてみてはどうでしょうか？
https://qiita.com/pea1205/items/930e920e027e3bf9d8a3
後は、ラージオブジェクトを使っている場合は孤児ラージオブジェクトの削除にvacuumloツールが使えます。
ご紹介いただいたqiitaの記事は３つに分かれていたので全て読みました。まず内容はSELECTがほとんどで実処理よりも状況把握を主においているもので現実として「ストレージ容量を減らす」ためのSQL文はほぼ無いように思います。またインデックス関連について書かれていましたが、インデックスは使っていません。
vacuumloをこれから試してみたいと思います。
不要領域がないのでしたら、カラムの型最適化や不要な更新を減らす等を地道にやる必要があります。
不要領域がないということで状況把握しないことには、データ削減は難しいと思います。
手段を問わないのでしたら、ファイルシステムの圧縮機能を使う方法がありますが、一般的な対策方法ではなくお勧めはしません。
流石に、バックアップデータとオリジナルデータのサイズ比較は無圧縮同士で比較しているものと思いますが、不要領域がなくてそこまで差が生まれるのは不思議ですね。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。