[pgsql-jp: 26095] Re: コンカレントバキュームについて

sugita @ sra.co.jp sugita @ sra.co.jp
2002年 5月 23日 (木) 20:59:02 JST


  杉田です。

From: Jun Kitamura <kitamura @ zoozee.jp>
Subject: [pgsql-jp: 25834] Re: コンカレントバキュームについて
Date: Mon, 06 May 2002 01:35:39 +0900

# メイルを整理していたら、ここはフォローがないようなので、、、

;;; VACUUM 中でも SELECT,UPDATE等が可能ということから、MVCC の恩恵を受けてい
;;; ると想像できるのですが、トランザクションID(XID)の食いつぶしにどう対処した
;;; か、が問題ですね。(どう対処するか、じゃないところが情けないですが・・・)
;;; (PostgreSQL のトランザクション処理では、現在のトランザクションID(XID)より
;;; 低い XID 値を持つ行(古い行)は可視、高い値(新しい行(別トランザクションで更
;;; 新/削除中など))は不可視なので、最大値になった後 0に戻ってしまい(食いつぶ
;;; し)、ほとんど全ての行が不可視になってしまう。

  XID の大小でなく module-2^31 で環状にして、古い新しいで考え、ある程度古くなっ
たのを FrozenXID に押し込むのでうまく行きます。リングバッファと同様ですね。

;;;                                              旧来の VACUUM ではテーブルに
;;; ロックをかけて XID を整理していた(と思う))。

  旧来の VACUUM では、そのようでは対処できないはずです。initdb & reload が対処
方法です。

;;; 新しく、特殊な XID(BootstrapXID=1と FrozenXID=2)を導入し、対処しているよ
;;; うです。VACUUM が実行されると現在の XID より 1 billion (10億(*))以前のも
;;; のは、 XIDが 2 (FrozenXID)になります。

  その 10 億以前の閾値をカットオフ XID と言っていますね。

;;; そのため、XID が食いつぶされても(たぶん) 3 から始まって、

  3 です。

;;; ((*)英国では billion は 兆 ということですが、1兆ってのは無いですよね)。

# 10 億です。

;;; 明示的に XID を FrozenXID(=2) にする(現在のトランザクションより前のトラン
;;; ザクションを XID=2 にする)ためには、 VACUUM FREEZE を行なえとありますが、
;;; 一日一回 VACUUM すれば問題無いような。

  余裕を持って 5 億トランザクションごとがお勧めで、そうしていれば VACUUM
FREEZE はしなくてもよいです。VACUUM をするのは、

        postgres=# select datname, datfrozenxid, age(datfrozenxid) from
        pg_database;
          datname  | datfrozenxid |    age     
        -----------+--------------+------------
         postgres  |   3221229343 | 1073741874
         template1 |           49 |       3872
         template0 |           49 |       3872
        (3 rows)

        postgres=# 

この age が 15 億になった辺りが、引数なしの VACUUM を行う目安です。15 億古いの
ができたので、その中の 10 億より前のを FrozenXID に固めます。


Kenji Sugita
sugita @ sra.co.jp
  



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