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

[Tsunehisa Kazawa]

加澤です。

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

昨日の未明に上記のとおり設定を変更して backend を restart し、直後に
vacuum、それから１日半様子を見てみました (今朝にももう一度 vacuum が
走っています)。

効果は劇的でした。DB 全体の disk 占有サイズ増加率も激減しましたし、懸
案だった毎日数百Mbytes づつ大きくなってしまっていた table (まだ vacuum
full していない方) にいたっては 1bytes も増加しませんでした。ファイル
の実体のタイムスタンプは盛んに更新されていることから、きちんとゴミ領域
が再利用されているらしいことが分かります。

副作用としては、postgres が使う共有メモリ量が 17〜18Mbytes 程度増えた
ことと、ちょっと気になるのが、今朝の vacuum で例の 7Gbytes 以上に肥大
化してしまった table を処理している時に、7.1 までの vacuum 時に table
lock がかかった時のように、アプリケーション側で Connection timeout が
発生していたことくらいです。

＃アプリ側で timeout が発生する条件は、ConnectionPool (120 本) を使
＃い切ってしまい、Connection 待ちの thread が 30 秒以上待たされた時、
＃です。通常は一切発生しません。

ただ後者についてはまだちょっと原因がはっきりしないため、もうしばらく様
子を見たいと思います。前日に途中まで vacuum full を行っていたのを中断
したことや、その現象が発生した時の CPU 使用率、IO 使用率 (単に overload
だったのかもしれない) などを疑っています。

それでは。

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