2010年9月17日

[pgsql-jp: 40404] Re:AUTOVACUUMと手動VACUUMの同時実行

Itagaki様

下記ご回答誠にありがとうございます。

2010年9月14日14:43 Itagaki Takahiro <itagaki.takahiro@xxxxx>:
> 2010/9/13 Kei SUGIMOTO <kei.wings@xxxxx>:
>> 特定テーブルがVACUUM(AUTOVACUUM)中に、そのテーブルにUPDATE処理を実施した際に
>> 処理待ち状態となってしまいました。

>
> 確かに、VACUUMのゴミ取りの間は競合するようなロックはかからないのですが、
> VACUUMの最終ステップで行われる、テーブルファイルの末尾の切り詰め処理で
> 排他ロックが取得される場合があります。これにぶつかったのかもしれません。
>

そういう状況になることがあるのですね。

> 特に 8.1 等の古いバージョンだと、vacuum cost delay を設定していると
> この排他ロックの時間がムダに延びる問題が残っています。
> # たしか最近のバージョンだと改善されたはず。
>

AUTOVACUUM用のcost_delay設定はvacuum_cost_delayに従うように
なっており、vacuum_cost_delayの値は0、すなわち未設定状態です。

>> 今後の暫定対応としては該当テーブルの個別に通常VACUUMを実施する予定なのですが、
>> 個別VACUUM中にAUTOVACUUM処理でその他のテーブルのVACUUMが実施された
>> 場合、問題が発生するものでしょうか?
>
> "AUTO" であることが問題ではなく、VACUUM 全般で発生する可能性があります。
> 手動VACUUM時に あえて cost delay させないなど、調整が必要かもしれません。
>

了解しました。
現在の設定上、手動VACUUM時にcost delayさせていない状態と同様という
認識ですので、この状態で様子を見てみようと思います。

貴重なご意見、ご指摘誠にありがとうございました。

※一旦、該当テーブルのみAUTOVACUUMを無効化しておりますが
 未だUPDATE文の滞留は解決しておらず、本事象はVACUUMとは
 無関係である可能性が高くなってきました。
 実はこのUPDATE文はpgpool経由で発行したもので、
 そのUPDATE文を発行したpgpoolプロセスが残った状態のまま
 どんどんリソースを食ってしまっています。
 (詳細情報を先にお知らせすべきでした。申し訳ございません)

以上です。

> --
> Itagaki Takahiro
>


投稿者 xml-rpc : 2010年9月17日 16:38
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/98398
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。