[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 メーリングリストの案内