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

[Tsunehisa Kazawa]

貴重な情報ありがとうございます。加澤です。

Tatsuo Ishii wrote:
> まず気になるのが，「巨大化した」テーブルのサイズです．VACUUMをかける前
> にどの位の大きさになっていましたか?標準の設定では，78MB以上の空き領域
> をVACUUMは管理しないので，78MB以上の大きさのテーブルをうまく管理できな
> い可能性があります．postgresql.conf の max_fsm_pages * 8192 が問題のテー
> ブルの(VACUUM直前の)物理サイズ(単位:バイト)よりも十分大きくなるように
> してください．

table 本体の物理サイズ (FS 上のファイルのサイズ) は、?????.5 までいって
いましたから 5GBytes 以上、またその table に関連する pg_toast_?????
table がやはり ?????.7 までありましたので 7Gbytes 以上ありました。

max_fsm_pages のサイズを大きくすることの副作用は何かありますか？一応、メ
インメモリは常態でだいたい 512Mbytes 程度の余裕があります。

> また，このようにUPDATEが頻繁な環境でVACUUMが１日1回しか行われないのは
> 不足だと思います．ご存じのようにFULLなしのVACUUMはロックしないので，過
> 負荷にならない限りはもっと頻繁にVACUUMするべきだと思います．1時間に1回
> でもいいんじゃないでしょうか?

ご指摘感謝です。ピーク時には query/update 合わせて 360 transaction/sec
程度の負荷がかかっているのですが、その状態で平行して vacuum をかけても大
丈夫なものなのでしょうか？

> ところで，問題になっているテーブルに類似したテーブルが他にもたくさんあ
> る，ということはないですよね？その場合は max_fsm_pages をもっと増やす
> 必要があります．

update が同じくらい (daily で数百万以上) 頻繁な table、という意味では他
にもいくつかありますが、１ レコードの大きさが大きいテーブルはこれだけです。
他は大抵 int4 型が 3〜4 つと timestamp 型、というような構成です。

本当に、いつも貴重な情報感謝します。

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