問題タブ [autovacuum]

Postgres v11.9

Postgres ログには、次のような多くのエラーがあります。

手動バキュームもこのエラーで失敗します。

このエラーを修正するにはどうすればよいですか?

自動バキュームは、しきい値を超えるとバキュームと分析を実行します。しきい値は次のとおりです。

• autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * 行
• autovacuum_analyze_threshold + autovacuum_analyze_scale_factor * 行

PostgreSQL で、自動バキュームのバキュームを自動的に実行したまま分析を停止する方法はありますか?

PostgreSQL データベースのエラー ログで 1 日中このエラーが生成され、翌日もエラーが続く

エラーには、システム カタログ ( pg_catalog.pg_largeobject、pg_catalog.pg_largeobject_metadata) が関係しています。

この 2 つのテーブルで自動バキュームを無効にした場合の修正方法や影響について、サポートが必要です。

ノート：

• DB : PostgreSQL バージョン 11.6
• OS : Red Hat Enterprise Linux Server リリース 7.8

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 月にさかのぼります。

明確化を歓迎します。