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

Tatsuo Ishii t-ishii @ sra.co.jp
2002年 5月 22日 (水) 16:50:23 JST


石井です.

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

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

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

free space mapは共有メモリに取られるので,その分共有メモリに余裕が必要
になります.私の計算では,max_fsm_pages = 2000000 とすると,7756(ペー
ジ数に関わらないオーバヘッド)+6.25(1ページあたりに必要なメモリ)
*1048576 = 12507756バイト = 12MBほど共有メモリが必要になります.細かい
数字はOSによって変わると思いますが,だいたいこんなものでしょう.つまり,
12MBほど共有メモリに余裕があれば必要なfree space mapが確保できることに
なります.

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

こればっかりはやってみないと分かりませんね.

> > ところで,問題になっているテーブルに類似したテーブルが他にもたくさんあ
> > る,ということはないですよね?その場合は max_fsm_pages をもっと増やす
> > 必要があります.
> 
> update が同じくらい (daily で数百万以上) 頻繁な table、という意味では他
> にもいくつかありますが、1 レコードの大きさが大きいテーブルはこれだけです。
> 他は大抵 int4 型が 3〜4 つと timestamp 型、というような構成です。

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

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

どういたしまして.結果がどうだったかお知らせ下されば幸です.私もこんな
に大きなテーブルのケースを試したことがないもので:-)
--
Tatsuo Ishii



pgsql-jp メーリングリストの案内