@syumari Mayaさんのスレッドにぶら下がってたので一旦切りました。
ストレージがキツイ時は、まず空き容量が確保できるかが問題です。空きがあまりない場合は、バックアップしてリストアする方が簡単かもしれません。
また、そもそも余分な情報が多すぎるなら、先にtootctl statuses removeでリモート投稿のキャッシュを削っておくと効果が大きいです。
https://qiita.com/kumasun/items/870769d7db4d95cde238#過去の投稿を削除するremovev280rc1
VACUUMについては、この記事の説明のところに別ページで色々説明してくれてるので、そこを見るといいと思います。単に実行するだけじゃなくて、事前に調査する方法から書いてあります。
pg_repackはインデックスも再構成してくれるので心強いです。
十日町市のMastodonのハルさんの記事を参考にするといいかも。
https://qiita.com/west2538/items/a82827ece65469c8c2be
@noellabo 以前それとなくpostgresql.confでautovacuumの項目の#を外して鯖再起動してみたんですが上手く動いてないっぽくて。
これは今回みたいにstatus removeなどでDBのテーブルに削除フラグを立てないと意味がないということなんでしょうか。
@syumari ウチはautovacuumは有効にしてません。たまにpg_repackかける程度です。丁度良いのでやってみましょう。
こちらのクエリを借りてきてます。
http://ritchiekotzen.hatenablog.com/entry/2015/01/21/postgreSQL_で不要領域の比率を出すクエリ
SELECT
relname,
n_live_tup,
n_dead_tup,
CASE n_dead_tup WHEN 0 THEN 0 ELSE round(n_dead_tup*100/(n_live_tup+n_dead_tup) ,2) END AS ratio
FROM
pg_stat_user_tables;
ratioが高めかな。
statuses removeは無しで行きます。
…………実行中…………終了。
33.9GBから26.3GB。
7.6GBほど削減できましたね。
#fedibird
@noellabo ありがとうございます。まずは status removeを実行してみます。