[pgsql-jp: 36379] Re: VACUUM の性能を向上させたい

hogehoge kazubonbonk @ yahoo.co.jp
2005年 11月 12日 (土) 13:55:07 JST


こんにちは。木村@横河電機です。
元、Oracle使いです。

> 結果は以下の通りでした。
> 
> 【デフラグ前】
> ---------------------------------------------
> DBデータ領域(psql/data)の断片化率
> ---------------------------------------------
> f-per 28.45%
> fblocks 1575479
> frags 448294
> sfrags 0
> ---------------------------------------------
> VACUUM ANALYZE 所要時間
> ---------------------------------------------
> 約90分
> ---------------------------------------------
> 
> 【デフラグ後】
> ---------------------------------------------
> DBデータ領域(psql/data)の断片化率
> ---------------------------------------------
> f-per 0.00%
> fblocks 1544408
> frags 98
> sfrags 0
> 
> ---------------------------------------------
> VACUUM ANALYZE 所要時間
> ---------------------------------------------
> 約15分
> ---------------------------------------------
> 
> 以上より、ファイルの断片化がかなりVACUUMに影響していた
> ことがわかりました。
154万ブロックと言うことは、791MBですか。
でかいですね。ウチの10倍以上ですね。(^^;
これに対して、大量の更新が発生すると言うことが、
フラグメントが大量に発生することにつながっているん
でしょうね。
Postgresは、新規・更新データをファイルの後ろに追記
する方式だから、書き込んだデータに対して数KB単位で
ディスク上にランダムに領域が確保される事になり、これ
がフラグメントの原因でしょう。
これに対して、Oracleは、最初に表領域というディスク
スペースを事前に確保し、その表領域の中にエクステン
ションと呼ばれるフラグメントを自前で確保するやり方
です。なおかつホールを管理しているため、VACUUMは不要
です。
但し、エクステンションの数が50個を超えると検索が
とっても遅くなります。30個以内になるようにチューニ
ングするのがミソです。

Izumiさんのアプリケーションの場合、Oracleにした方が
難しい管理が省けて良いような気がします。
定期的に、
> ・psql/data ディレクトリ以下をコピー、削除、再コピーし
て、
>  断片化解消(デフラグ)
をするのは、ミスも出るので止めた方が良いと思います。

VACUUMしなくて良いけど、Oracleの管理自体が面倒なので
うんざりといえばうんざりですが。
また、金をむしり取られるのが癪に障りますが。(^^;

> 現在は、1日でどの程度フラグメントするかを計測中です。
> また、デフラグを定期的に実施することが難しい環境なので
> PostgreSQL8.1.0でこの辺り(フラグメント発生率)が
> 改善されていないか、試してみる予定です。
MicrosoftもNTFSはフラグメントが発生しないとか、昔言って
いたような(^^;
フラグメントは、発生率ではなく、フラグメント総個数が
問題でしょう。フラグメントブロック数が1万を超えると
やっぱり遅いような気もします。


--------------------------------------
Yahoo! Mail - supported by 10million people
http://pr.mail.yahoo.co.jp/10m/




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