[pgsql-jp: 38095] Re: コミット待ちトランザクションのメモリ消費量について

2007年 2月 27日 (火) 19:21:16 JST

こんにちは山崎です.

永安さんの意見とほとんど同じですが,Commit前にWALバッファが
いっぱいになった場合のシナリオが気になります.

1. Commit前にWALバッファがいっぱいになった場合,
PostgreSQLはデータディスクにデータ内容を書き込む.

2. だけど最近のPostgreSQLはMVCCを搭載してるので,
書き込んだデータは未コミットの別バージョンのデータとして
取り扱われる.よって書き込みデータが多くなってもメモリを
食うことはなく,書き込むためのディスクがある限りは問題ない.

3. よって結論としてはOracleでいうところの「ロールバックセ
グメントがあふれる」に相当する現象はおきない.

というのが私の理解ですがあってますか?

On Tue, 27 Feb 2007 16:46:21 +0900
Satoshi Nagayasu <nagayasus ＠ nttdata.co.jp> wrote:

> 永安です。
> 
> > 共有メモリなどのことを調べてみても
> > 出てくる話題は検索時のキャッシュなどのことが多くて・・・
> > 「未コミットのまま、処理を続けるとどんな影響があるのか」
> > についての話題を見つけることができなかったので・・・
> > （話題にするレベルでもない？？）
> 
> 未コミットの更新情報は、「WALバッファ」と呼ばれる領域に乗ります。
> postgresql.conf の wal_buffers の部分ですね。
> 
> WALバッファの内容がディスクに書き出されるケースは大きく二点、
> 「トランザクションがコミットされた時」か
> 「WALバッファが足りなくなったとき」です。
> 
> ですので、未コミットのまま継続しても、
> メモリの制限などが制約となることはあり得ないと思います。
> 
> > 1. 登録・更新・削除すると直接ファイルに書き込みに行く
> > （ロールバックされるとゴミ領域として残る→VACUUMで処理）
> > 2. コミットされるとWALに書き込まれる。
> > 3. 遅れてWALから各データファイルに書き込まれる。
> > （直接書き込んだデータの更新？）
> > という感じなんですが・・・
> > 間違っていますか？
> 
> 1. 登録・更新・削除すると、WALに書き込み、共有バッファを変更する
> 2. コミットされると、WALに（コミットを）書き込み fsync する。
> 3. 遅れて共有バッファの内容をデータファイルに書き込む
> 
> という流れになります。
> 
> WALは「Write-ahead log」ですので、（共有メモリ内の）レコードを
> 更新するより前に記録されることになります。
> 
> このあたりは、WEB+DB PRESSの連載「PostgreSQL安定運用のコツ」の
> 第1回（Vol.32）、第4回（Vol.35）あたりに少し書きましたので、
> よろしければご参照ください。
> 
> 松本 康寛 wrote:
> > 松本です。
> > ご返答ありがとうございます。
> > 
> >> そもそもメモリ消費量は未コミットの変更量に依存するのですか?
> >>
> >> ロールバックに必要なデータはデータファイルの中に書いてあるし、
> >> REDOに必要なデータはWALファイルの中に書いてあるから、
> >> ちょっと考えて実装すると、そうはならないようにできるはずなん
> >> ですが、実際はどうなんですかね?
> >>
> >> 例えばOracleも、ロールバックセグメントが大量に食われるという
> >> のはありますが、メモリが食われるというのは聞いたことありませ
> >> んし。
> > 
> > 
> > そうなんです。
> > 共有メモリなどのことを調べてみても
> > 出てくる話題は検索時のキャッシュなどのことが多くて・・・
> > 「未コミットのまま、処理を続けるとどんな影響があるのか」
> > についての話題を見つけることができなかったので・・・
> > （話題にするレベルでもない？？）
> > 
> > しかし、仕事ではコミットする件数が決められていることが多ので・・・
> > で、理由を聞くとメモリの話になります。
> > 裏づけのある理由ではなく、源泉は「感覚的・経験的」です。
> > 
> > そもそも
> > 実際のファイル書き込みってどうなっているしょうか？
> > 私が調べたレベルでは
> > 1. 登録・更新・削除すると直接ファイルに書き込みに行く
> > （ロールバックされるとゴミ領域として残る→VACUUMで処理）
> > 2. コミットされるとWALに書き込まれる。
> > 3. 遅れてWALから各データファイルに書き込まれる。
> > （直接書き込んだデータの更新？）
> > という感じなんですが・・・
> > 間違っていますか？
> > 
> > 
> >> ところで、後学までに教えて欲しいのですが、
> >>
> >> > 単純にバッチ開始実行前にバックアップを
> >> > 取っておけばいいわけですが、リアルタイムバッチの場合は
> >> > その方法は使えないですし・・・
> >>
> >> リアルタイムバッチって、どういうものなのでしょう?
> > 
> > 不適切な表現ですね。申し訳ありません。
> > ・一括でまとめて処理する機能をバッチ処理
> > ・「夜間バッチ」の対として「リアルタイムバッチ」
> > （日中にユーザオペレーションなどで実行される一括処理）
> > と、私の所属している作業場では表現しています。
> > 
> > ご意見ありがとうございました。
> > 
> > 
> > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
> > 
> > 　松本　康寛　（マツモト　ヤスヒロ）
> > 
> > E-mail　：wochenendhaus ＠ hotmail.com
> > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
> > 
> > ※利便性などを考えて、Hotmailを使用しております。
> > 　何卒、ご理解を賜りますようよろしくお願いします。
> > 
> > _________________________________________________________________
> > ライブ映像を配信する「MSNミュージック LIVE PERFORMANCES」がスタート！ 
> > http://music.jp.msn.com/lp/
> 
> 
> -- 
> NAGAYASU Satoshi <nagayasus ＠ nttdata.co.jp>
> Phone: +81-50-5546-2496

-- 
プログラマ集団 スケールアウト
Daisuke Yamazaki <yamajaki ＠ gmail.com>
Blog：最速配信研究会
http://d.hatena.ne.jp/yamaz/