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

[Tsunehisa Kazawa]

森田さん、はじめまして。加澤と申します。

Morita Kazuro wrote:
> 私はゲームのサイトをいくつか運営しておりまして、データベースには
> Postgres の 7.4.6 などを使っております。その中の一つは非常にアップ
> デートが激しく、定期的な vacuum がかかせません。それで、いつも朝の
> 04:00に定期メンテナンスをして、vacuum analyze と pg_dump をやって
> います。vacuum analyze にだいたい１５分くらいかかっています。それと、
> pg_dump が１分くらいなので、１６分くらいかかります。
> 
> ところが、時々新規の機能のテストを行うテストサーバーにメンテナンスの
> 時に pg_dump で作ったデータを持っていくのですが、この作業をする時間が
> pg_restore に１分、そのあとは必ず、vacuum analyze をやっていますが、
> これは 20秒くらいで終わってしまいます。
> 
> そこで、疑問に思うのですが、毎日のメンテナンスで
> 
> 1.vacuum analyze
> 2.pg_dump
> 
> とすると１６分くらいかかるのですが、
> 
> 1.pg_dump
> 2.dropdb
> 3.createdb
> 4.pg_restore
> 5.vacuum analyze
> 
> とすると３分以内で終わってしまいます。
> 
> しかし、後者の方法を薦めたものは見たことが無いので、なにか問題があるのでは
> ないかと思うのですが、具体的にどういう問題があるかお教え願えないでしょうか？

ぱっと思いつくのは、前者のパターンは完全に無停止で実行出来るのに対し、後
者のパターンでは 1.〜4. の間、ユーザからのアクセスを停止しなければならな
いということです。

その３分間の停止期間を許容できるのであれば、後者の方がかかる時間も少ない
ですし処理完了後のテーブルも綺麗になりますから、僕もよりベターだと思います。

// vacuum はゴミ領域を回収する、という処理であるからして、
// ゴミ領域の量によって処理時間が大幅に変化しますね。

僕も、dropdb/createdb ではありませんが、バッチ的にしか更新されない DB に
対して、

1. 新本番 table を create
2. 新本番 table に data を copy
3. 新本番 table を analyze
4. 旧本番 table と 新本番 table を swap (alter table 〜 rename to 〜)
4. 旧本番 table を drop

という形の処理を書いたことがあります (実際には create/drop の代わりに
truncate を使いましたが、本質的には同じです)。なお当初の目的は、アクセス
中のテーブルに対してバッチが大量の更新をかけると激しく性能ダウンしてしま
うことがわかり、それを避けるためだったのですが、結果的に vacuum しないで
すむ、というメリットも生まれました。

// あ、そういえば、copy を早くするために index の
// drop/create も行っていたんでした。

もう一つ drop/create 案の些細な欠点をあげるとすれば、例え全 table を
WITHOUT OIDs として生成していたとしても、定期的に OID を消費してしまう、
ということあげられるでしょうか (create する際に新しい OID が割り当てられ
ます)。OID には明確な上限がありますから、確実に「寿命のあるシステム」と
いうことになってしまいます。何十億もの OID を create 〜 で消費するにはと
てつもない時間がかかるとは思いますけれど…。

＊＊＊

ところで、関係のないメールの返信として新しいトピックスをメールするのは、
メーリングリストアーカイブでのスレッド表示が乱れてしまうため避けた方が良
いと思います。
http://ml.postgresql.jp/pipermail/pgsql-jp/2005-April/thread.html

それではまた。

-- 
  ◇   加澤恒央 Tsunehisa KAZAWA
◇  ◇ mailto:kazawa ＠ ca2.so-net.ne.jp
  ◇   http://www.digitune.org/