PG 12 でテーブルの 1 つが大幅に拡大していることに気付きました。このテーブルは、非常に大きなtext列 (多くの場合 50kb を超えるデータ) を含む列の種類が混在する、非常に頻繁な更新の対象です。ローカル cron を実行します。 X 時間より古い行を検索し、text列を null 値に設定するジョブ (X 時間後にその特定の列のデータが不要になるため)。
MVCC モデルのため、これによって実際にディスク容量が解放されないことは理解していますが、自動バキュームがこれを処理してくれることを期待していました。驚いたことに、テーブルは自動バキュームを実行せずに成長し続けています (現在 40 GB 以上の価値があります)。バキュームを手動で実行することで問題が解決され、増加は見られなくなりました。
これにより、他のテーブルを調査するようになりました。自動バキュームがどのようにトリガーされるのかまったく理解していないことに気付きました。
これがどのように機能するかについての私の理解です。誰かが分解できることを願っています。
- デッドタプルが大量に含まれているテーブルを探します。
select * from pg_stat_all_tables ORDER BY n_dead_tup desc; tableX33169557 個のデッド タプル (n_dead_tup 列)を識別します。- を実行して
select * from pg_class ORDER BY reltuples desc;、テーブルにある推定行数を確認しますtableX - 列を介して 1725253 行を識別し
reltuplesます。 - 自動バキューム設定を確認します:
autovacuum_vacuum_threshold = 50そしてautovacuum_vacuum_scale_factor = 0.2 - 数式を適用すると、
threshold + pg_class.reltuples * scale_factor345100.650 + 1725253 * 0.2が返されます。
~345100 個のデッドタプルが見つかると、このテーブルで自動バキュームが開始されることを私は理解しています。しかしtableX、すでになんと 33169557 デッドタプルに達しています! 、このテーブルの last_autovacuum は 2 月にさかのぼります。
明確化を歓迎します。