postgresqlサーバーのディスク容量がいっぱいになってしまった
ちょー簡単な概要
実験管理のためにpostgresqlを使っている。実験結果をpostgresqlデータベースに保存している。実験結果にはシリアル化したパラメタ情報も含む。予想よりも実験計画が長期化して、そして、とうとう物理的にディスクが満杯になってしまった。
いろいろ試してみた。が、どうにもならなかった。
ディスクの確認
postgresqlのデータ専用に200GBのディスクを割り当てている。
df -h コマンドを利用すると、ディスクは200GBを利用している。
そして、ディスク不足のためにpostgresqlサービスが停止し、起動も不可能になってしまった。
postgresqlサービスを起動できるように
まずは、サービスを起動できなければ話にならない。ギリギリでも容量をつくり、サービス起動可能にする。
pg_wall ディレクトリのサイズが割と大きめだったので、このディレクトリが怪しい。ファイルを削除可能かどうか、と調べてみる。
この記事を見る限りでは、いくつかのwallファイルは削除可能なようだ。wallファイルを削除し、200MBくらい確保した。
ちなみにpg_wallを不要に削除しまくると、transaction管理が狂う。結果的にpostgresqlサービスが起動しなくなることもある。そんな場合は pg_resetwal コマンドを利用する。記事
サイズと問題の確認
まずはサイズを確認し、問題を理解する。
|
1 |
select relname, pg_relation_size(relid) as capacity from pg_statio_all_tables order by capacity desc limit 5; |
実行結果
|
1 2 3 4 5 6 7 |
relname | capacity ---------------------------------+-------------- pg_toast_143999 | 207412060160 pg_toast_187814 | 76365824 pg_toast_143993 | 62152704 pg_toast_192344 | 16588800 |
toastテーブルが200GB超えのサイズを保持している。シリアル化した実験結果が溜まり、そして200GB近くのサイズになったのだろう。
pg_repack?
postgresqlのディスクが満杯になった場合、pg_repack コマンド利用が一般的。
でもpg_repack はかなりの空き容量を必要とする。だから、この状況下では利用不可能。
vacuumは効くか？
実験結果のうち、すぐに必要ない行を削除する。ああ、時間かけたのに、もったいない。
vacuumコマンドを実行してみるも、ディスク容量は特に増加しなかった。vacuumコマンドがディスク容量に関係しないことはよく知られている。仕方がない。
落としどころ
ディスクは満杯のままでどうしようもない。仕方がないので、まずはネットワークディスクへsqlダンプファイルを書き出す。
いったん、postgresqlサービスを初期化し、sqlダンプファイルから復元することにした。
ついでに、toastテーブルの原因も調査してみる。
