[pgsql-jp: 26077] Re: 7.2 の vacuum

[Tsunehisa Kazawa]

加澤です。

Tatsuo Ishii wrote:
> なるほど．ということは，仮に合計15GBとして，15*1024*1024*1024/8192 = 1966080
> ページですね．余裕を見て2000000位にmax_fsm_pagesを設定する必要がありそ
> うです．

とりあえず max_fsm_pages の値を 2621440 (切りのいいところで :-D) と
して backend を restart し、しばらく様子を見てみたいと思います。

この、15Gbytes という数字は、デフォルト設定で full でない vacuum を
毎日行い、それが２週間経って肥大化してしまった後のもので、その後 7.1
時代のログを調べてみると、daily の vacuum でだいたい 3Gbytes 程度の
領域が開放されていたようです。つまり、毎日生じるゴミ領域のサイズはだ
いたい 3Gbytes くらいである、と言えると思います (その時は DB 全体の
サイズはだいたい 12Gbytes 程度でした)。

この max_fsm_pages のサイズは、物理的なテーブル全体のサイズによるの
でしょうか？それとも、物理的なファイルに含まれる、日々 update や delete
によって生まれるゴミ領域のサイズによるのでしょうか。

> 問題はテーブルの物理的なサイズです．他のテーブルが，問題になっているテー
> ブルと比べて無視できるほど小さければ良いのですが，そうでなければもっと
> max_fsm_pageを増やす必要があります．

今現在全 table を合わせて物理的なファイルのサイズは 20Gbytes ほど
(今朝 5Gbytes あった table を vacuum full したところ 270Mbytes く
らいになりました。もう一つの肥大化した table を vacuum full してい
たところで時間切れとなり、処理を停止したためそちらはそのままです) で
すから、とりあえず上記設定で様子を見て、間に合わないようでしたら vacuum
回数を増やすようにしていきたいと思います。

新井さんお薦めの定期的な vacuum full の実行は、daily では運用上難し
いため、monthly に行われるシステムを停止させてのメンテナンス時に行う
ようにしたいと思います。ご助言感謝します。

結果は後日お知らせいたします。本当にありがとうございます。

-- 
加澤恒央
Tsunehisa KAZAWA
kazawa ＠ sons.co.jp
SONS,. Ltd. Programmer