[pgsql-jp: 39650] Re: データの断片化

[ichikawa kenji]

市川 健児 です。

お返事、ありがとうございます。

postgresql.conf の max_fsm_pages は

max_fsm_pages = 100000

vacuum の実行結果を見ると、

DETAIL:  A total of 5136 page slots are in use (including overhead).
5136 page slots are required to track all free space.
Current limits are:  100000 page slots, 1000 relations, using 651 KB.

max_fsm_pages の値は十分そうに思えるので、
一日一回の vacuum の回数を増やしてみます。

また、アプリケーションを停止できるときに REINDEX を実行して、
パフォーマンスを確認してみます。



On Tue, 18 Nov 2008 18:05:44 +0900
FUKUSHIMA Katsuaki <kfukushima ＠ sis.seino.co.jp> wrote:

> 福島です。
> 
> vacuum は1日1回実行ということですが postgresql.conf の max_fsm_pages
> の値が、削除される１日分のフリースペース管理しきれない小さな値になっ
> ているということはないでしょうか？この場合 vacuum を実行しても、削除
> スペースの再利用が行われません。PostgreSQLの場合、更新 = 削除 + 追加
> なので、更新が多い仕組みだと、その分フリースペースが大量に発生し、
> vacuum を掛けない限り再利用されない状況になります。
> 
> また、更新が非常に多いということですが index が肥大化している可能性
> もありますね。更新の多いテーブルの index に対して定期的に reindex を
> 掛けることで、回復することもあります。
> 
> 
> ichikawa kenji さんは書きました:
> > 市川 健児 です。
> > 
> > PostgreSQL 8.1.3 を運用しておりますが、
> > 特定のテーブルに対する更新が多く、データの断片化により、
> > PostgreSQL を運用しているサーバが高負荷状態になってしまい、
> > アプリケーションのパフォーマンスに影響が出ております。
> > 
> > 24時間稼動を前提としているデータベースのため、
> > 通常の vacuum のみを一日一回、実行し、
> > full vacuum は実行しておりません。
> > 
> > 現在は、ほぼ月に一度程度発生する、 高負荷状態に陥ったときは、
> > アプリケーションを停止させ、
> > データベースそのものを pg_dump を使ってダンプさせて、
> > データベースを再構築することで対応しております。
> > 
> > 対応として、tablespace の利用や PostgreSQl 8.3 への
> > アップグレードを考えておりますが、私と同じようにデータの断片化により、
> > パフォーマンス劣化を経験された方からのアドバイスをいただきたく、
> > メーリングリストに投稿させていただきました。
> > 
> > よろしくお願いいたします。
> > 
> > 
> > 
> > 
> > ------------------------------
> > ichikawa kenji
> > mailto:ichikawa ＠ fancs.com
> > http://www.fancs.com/
> > 
> > 
> > 
> > 
> 
> 
> -- 
> ---------------------------------------------------------
> FUKUSHIMA Katsuaki at Seino Information Service Co., Ltd.
> e-mail   kfukushima ＠ sis.seino.co.jp

------------------------------
ichikawa kenji
mailto:ichikawa ＠ fancs.com
http://www.fancs.com/