[pgsql-jp: 26978] 大規模運用でのVACUUM

Makoto Komatsu eurah @ mediafront.co.jp
2002年 8月 12日 (月) 14:13:31 JST


小松@メディアフロントです。
VACUUMに関する相談です。

現在抱えているプロジェクトでレコード数が500万弱あります。
データベースのサイズは5GBちょっとです。
XMLPGSQLを使っていて、要はXMLのノード数が500万ノード近く
ということなんですが、たぶん今後もノード数が増え続けるので
1000万レコードくらいは覚悟しておかないといけない様子です。
単純計算では10GBオーダーのデータベースを運用保守することに
なります。

バックアップするだけでも気が遠くなりそうなんですが、それは
さておき、VACUUM処理に膨大な時間がかかっています。

VACUUMをかけるともちろん検索は速くなるのですが、頻繁にやると
バックエンドの負荷が増して全体のパフォーマンスが落ちます。

現在のところでは1度のVACUUMに最大で40分程度はかかっている
状態です。
それで最初は10分に1度だったVACUUMを現在は1時間に1度にして
いますが、VACUUM時間が長くなると1時間に1度でもジョブが溜まる
事態になりそうです。

頻繁にUPDATEがかかると、最悪常にVACUUMが動いている状態に
なってしまいます。

世の中で500万ノードものXMLプロジェクトはそんなにないのでは
とも思いますが、RDBということではPostgreSQLでも事例がある
だろうと考えています。
たぶんこのくらいになると大規模DBと呼んでもいいのかなと思って
いるのですが、こういうものを皆さんはどのようなポリシーで保守
しておられるのでしょうか?

VACUUM FULLは1週間に1度にして、VACUUM ANALIZEを1日に1度行い、
VACUUMは1時間に1度にする、とか、
検索パフォーマンスを監視するためのSQLを定期発行して、基準値を
越える時間がかかるようになったらVACUUMをかけるとか、何か
合理的な方法がないものかなあと悩んでいます。
ケースバイケースなんでしょうか?

だんだんPostgreSQLそのものの限界と闘いつつあるのかなと感じ
まして、こちらへ投稿させてもらいました。

現在の環境は以下のようになっています。
PostgreSQL:7.2.1
CPU       :PIII 1.4GHz x 2
Kernel    :Linux 2.4.18-smp
Memory    :1GB
HDD       :128GB aacraid

ぜひアドバイスを頂きたく、よろしくお願いします。

--
Makoto Komatsu
MediaFront Inc.




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