VACUUM ANALYZE の頻度について

質問

表題の件について質問させてください。

環境は
PostgreSQL8.2.1
pgpoolにてDB2台で運用しております。

現在、とあるECサイトの運用などに携わっております。
1日平均が２～３千件の注文があり、注文情報を格納してるテーブルが150万件くらいになっています。
元々の作りが全てその注文テーブルに色々な情報を持たせてしまっており、更新頻度も結構高いです。

その状態で、現在は3時間に1回VACUUM ANALYZEをかけているのですが、その影響かはわからないのですが、セッション数(pg_stat_activityの件数)が正常運用時の3倍程度になる事が、ここ最近頻発しており、サイト全体の処理速度に影響しております。

１．VACUUM ANALYZEは、ロックがかからずにSELECT,UPDATE,INSERTなどが出来ると認識しておりますが、実行中に更新がかかっても問題ないという認識はあっておりますでしょうか？
ロックがかかったまま、セッションに残ってしまっているのは別の原因という事であっていますでしょうか？

２．VACUUM ANALYZEの頻度として、3時間に1回という頻度は多いのでしょうか？
やはり、pg_stat_activityで監視をしていると、VACUUM ANALYZEの処理に時間がかかって、セッション数が多くなり、処理速度にかなり影響をあたえているのでは無いかと言う気がしてなりません。

以上、２点について、何かご教授頂ければ幸いです。
宜しくお願い致します。

回答No.1

gentaro · ベストアンサー

私の担当する顧客のPostgreSQL－DBも120万件以上のデータがあります。
1・お使いのバージョンであれば問題ないはずです。ただし、VACUUM時にSELECTなどのレスポンスは当然落ちます。

2・私の方針（笑）では、キー情報のUPDATEが多くない限り、VACUUM ANALYZEまたはFULLは、多くても１週間に１回しかVACUUMしません。
DBの構造にもよりますが、２～３千件のINSERTで3時間に1回のVACUUMは
多い気がしますが、3時間に1回VACUUMしないとレスポンスが悪いのでしょうか？
このあたりはマシンのスペックによってもかなり影響されるので、はっきりとした答えは出ないでしょう。

検索などのレスポンスが悪い場合は、ANALYZEも有効ですが、やはり
定期的にdump＆restoreするのが一番いい方法なんですがね。
ノンストップ運用なら無理ですが・・・・

お礼

時間がたっているにも関わらず、ご丁寧な回答ありがとうございます。

なるほど。
やはり、3時間に1回は多いですよね。

＞ただし、VACUUM時にSELECTなどのレスポンスは当然落ちます。

そうですよね。
ここ最近は、VACUUM時にレスポンスが落ちて、DBに負荷がかかってしまってレスポンスが全然返ってこなくなってしまったりする現象が起きてます。。

＞定期的にdump＆restoreするのが一番いい方法なんですがね。

こちらの方法も可能かどうか検討してみます。
ありがとうございます！