PostgreSQL8.3系のAutovacuum不備？

質問

PostgreSQL8.3系のAutovacuum不備？
現在、8.3.3を使用しておりますが、最近応答がかなり重くなりまして
手動にてvaccumを実施し対処しました。
インストール時のデフォルトで運用しているのですが
＜値＞
autovacuum | on
autovacuum_analyze_scale_factor | 0.1 autovacuum_analyze_threshold | 50 autovacuum_freeze_max_age | 200000000
autovacuum_max_workers | 3
autovacuum_naptime | 1min autovacuum_vacuum_cost_delay | 20ms autovacuum_vacuum_cost_limit | -1 autovacuum_vacuum_scale_factor | 0.2 autovacuum_vacuum_threshold | 50

かなり動作が重くなっても、自動実行されない模様です（閾値が合わない）。

そもそもチューニングすべき物なのでしょうか？
お詳しい方、ご教授頂けないでしょうか？宜しくお願い致します。

回答No.1

yamada59 · ベストアンサー

VACUUM が適切に実行されずに性能が低下していることを前提として回答します。

更新頻度の高い巨大なテーブルが存在する場合には、自動バキュームの設定をテーブルごとに調整したほうがいいと思います。

デフォルトの設定のままでは、UPDATE や DELETE で不要になった行が 50 行 (autovacuum_vacuum_threshold) + 全行数の 2 割 (autovacuum_vacuum_scale_factor) を超えた場合に VACUUM が実行されます。

例えば、テーブルの行数が 100,000 行の場合には不要な行が 20,050 行を超えると VACUUM が実行されますが、100,000,000 の場合には 20,050,000 行を超えるまで実行されません。同じ 2 割であっても 2 万行と 2 千万行では性能への影響が違います。

PostgreSQL 8.3 であれば、pg_autovacuum テーブルにエントリを追加すればテーブルごとに自動バキュームの設定を行うことができます (参考 URL を見てください)。

あと、その他に気になることとしては、デフォルトでは自動バキュームで同時に起動できる VACUUM は 3 つ (autovacuum_max_workers) までなので、更新頻度の高いテーブルが大量に存在する場合には、自動バキュームが特定のテーブルへの VACUUM につきっきりになってしまい、VACUUM の実行されないテーブルが発生して性能が低下してしまう場合があります。

参考URL：

http://www.postgresql.jp/document/8.3/html/catalog-pg-autovacuum.html

お礼

yamada59様　早々のレスありがとう御座います。
大変参考に成ります。
９２テーブルの内、１、２テーブルが日の更新作業にて、
１万数千レコードのごみデータが、発生します。
社内テスト用ＤＢサーバで試しまして、本番へ適用したいと思います。