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

2007年 2月 27日 (火) 19:49:26 JST

永安です。

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

「データディスク」というのが、テーブルやインデックスの
ファイルを想定しているようでしたら、少し違っています。

正確には、WALバッファがいっぱいになった場合には、
「WALファイル」に書き込む、ということになります。

PostgreSQLでは、WALファイルとデータファイルが、
大きなI/O処理の対象となりますが、データの流れとしては、

[1.データ更新] --+--> [2.WALバッファ] ---> [4.WALファイル]
                 |
                 +-----> [3.共有バッファ] ---> [5.データファイル]

のようになっているはずです。

データが更新されると(1)、まずWALバッファに更新を行い(2)、
共有バッファのデータを書き換えます(3)。

WALバッファに書き込まれた更新情報は、COMMIT時、あるいは
バッファが溢れた時点でWALファイルに書き出されます(4)。

一方、共有バッファに行われた更新は、
チェックポイントあるいはバックグラウンドライタによって、
データファイル（テーブルやインデックス）に書き出されます(5)。

> Commit前にWALバッファが
> いっぱいになった場合のシナリオが気になります.

というわけで、WALバッファは固定サイズのメモリ領域であり、
溢れた場合には、単にその内容を逐次WALファイルに書いていくだけ
ですので、WALバッファが足りなくなるということは
基本的にはないはずです（パフォーマンスが落ちることはあっても）。

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

はい。これは起こりません。その理由は、

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

でおっしゃっている通りとなります。


Daisuke Yamazaki wrote:
> こんにちは山崎です.
> 
> 永安さんの意見とほとんど同じですが,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
> 


-- 
NAGAYASU Satoshi <nagayasus ＠ nttdata.co.jp>
Phone: +81-50-5546-2496