[pgsql-jp: 35366] Re: vacuum free についてお教えください

[Yutaka tanida]

谷田です。

On Sat, 23 Apr 2005 04:59:09 +0900
"Morita Kazuro" <morita ＠ yuki.ad.jp> wrote:

> 森田と申します。
> ほとんどはじめましてなのですが、実際には、何度か質問させていただいて
> 教えをいただいたことがあります。
> 
> 私はゲームのサイトをいくつか運営しておりまして、データベースには
> Postgres の 7.4.6 などを使っております。その中の一つは非常にアップ
> デートが激しく、定期的な vacuum がかかせません。それで、いつも朝の
> 04:00に定期メンテナンスをして、vacuum analyze と pg_dump をやって
> います。vacuum analyze にだいたい１５分くらいかかっています。それと、
> pg_dump が１分くらいなので、１６分くらいかかります。
> 
> ところが、時々新規の機能のテストを行うテストサーバーにメンテナンスの
> 時に pg_dump で作ったデータを持っていくのですが、この作業をする時間が
> pg_restore に１分、そのあとは必ず、vacuum analyze をやっていますが、
> これは 20秒くらいで終わってしまいます。

このような状況で考えられるのは

- updateが本当に激しくて、1日1回では不足している。ためにdead tupleが増え
すぎていて、vacuumに時間がかかっている。
- max_fsm_pagesが不足していて、dead tupleが減らない
- vacuumが十分でもindexが膨らんでいる
のように、極めて肥大化している状況です。

> そこで、疑問に思うのですが、毎日のメンテナンスで
> 
> 1.vacuum analyze
> 2.pg_dump
> 
> とすると１６分くらいかかるのですが、
> 
> 1.pg_dump
> 2.dropdb
> 3.createdb
> 4.pg_restore
> 5.vacuum analyze
> 
> とすると３分以内で終わってしまいます。
> 
> しかし、後者の方法を薦めたものは見たことが無いので、なにか問題があるのでは
> ないかと思うのですが、具体的にどういう問題があるかお教え願えないでしょうか？

よほど肥大化しないかぎり、後者の方法が速くなることはあり得ないからです。
実際、pg_dump/pg_restoreははっきり言って相当重いので・・・あとは、当然無
停止になりません。そこで、dump->createdb->restore->dropdb->vacuum
analyze->alter databaseでリネームすると停止時間が減ります。

ちなみにこれをするときに気をつけなければいけないのは共有テーブルのpg_database
とそのインデックスの肥大で、特に停止無しにpg_databaseのインデックスを
reindexする手段がありません。まあ、数百回ぐらいならなんの問題も出ません
が・・・

＃停止が許されるなら大丈夫か。

最後の秘密兵器はclusterコマンドで、このコマンドにはvacuum full相当のこと
ができる副作用があるので、肥大していることが分かっているテーブルに対して
これを実行すれば一気に軽くなることがあります。しかもvacuum fullより実行
時間が短くて。




-- 
Yutaka tanida <tanida ＠ sra.co.jp>