質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.23%

PostgreSQLのデッドロックについて

解決済

回答 1

投稿

  • 評価
  • クリップ 3
  • VIEW 7,755

al_aya_yuka

score 97

PostgreSQLの謎のデッドロックに苦しんでいます。

PHP Warning:  pg_q> uery(): Query failed: ERROR:  デッドロックを検出しました
DETAIL:  プロセス 8100 は ShareLock を トランザクション 624517 で待機していましたが、プロセス 6032 でブロックされました
プロセス 6032 は ShareLock を トランザクション 624508 で待機していましたが、プロセス 8100 でブロックされました
HINT:  クエリーの詳細はサーバログを参照してください in pg_load_test.php on line *
これがなぜ出てしまうのか、推測でも結構ですのでどなたか理由と解決策を教えてください。
エラーを再現できるスクリプトは以下です。

<?php
$dbh = pg_connect("host=localhost port=5432 dbname=postgres user=postgres");
while(1){
    $res = pg_query($dbh, "UPDATE public.table SET created = NOW() WHERE field = '*****'");
    if(!$res) exit();
}
条件句のfieldはINDEXが貼ってあり、複数列がHITします。
サンプルは無限ループですが、実際のバッチも数百万レコードを嘗めてUPDATEに向かいます。
このバッチは中身は一緒で並列稼働します。
最低2本の並列で事象が出ますが、実運用は7並列で稼働しています。
並列数が増えれば増えるほど、当たり前かもしれませんが、デッドロックの検出タイミングは早まります。

クライアント
    Windws7
    PHP5.6
サーバ
    PostgreSQL9.3.5
    CentOS6.5 or Windows7 (どちらでも発生を確認)

よろしくお願いします。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 1

checkベストアンサー

+1

>条件句のfieldはINDEXが貼ってあり、複数列がHITします。
update文で複数レコードが更新対象となることが原因と思われます。updateの処理を段階的に見ると、
  1.  whereで該当するレコード全てにロックを掛ける
  2.  ロックしたレコードを全て更新
  3.  ロック解放
の流れになります。並列する処理で「自分がロック獲得したいレコードを相手がロックしている」という関係が並列処理間で成立した場合、双方ロック獲得待ちとなりデッドロックとなります。レコードロックする順序が並列処理で同じなのであればデッドロックは発生しませんが、Indexが張られていたとしても列の値は同じなのでレコードロックの順序は処理で異なる可能性があります。そしてwhereに該当するレコード件数が多いほど(同じ値のレコードが多いほど)このコンディションが発生し易くなります。
対処としては、バッチの並列実行を辞めるか、ロックがぶつからないようにupdateのキーを別の物に変更する等になるかと思います。
対処について、追記します。バッチ処理を平行して実行しても対象のレコードが重複しないよう、バッチ処理別にwhere句に異なる抽出条件を追記する等です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2014/11/21 10:20

    コメントにダイレクトにお答えすると、
    処理A:「自分がロック獲得したいレコードを処理Bがロックしている。ロックしたいレコードが全部獲得できるまで持っているロックは解放しない」
    処理B:「自分がロック獲得したいレコードを処理Aがロックしている。ロックしたいレコードが全部獲得できるまで持っているロックは解放しない」
    というイメージでしょうか。

    キャンセル

  • 2014/11/21 10:52

    TaMahyuさん
    BlueMoonさん

    ご回答ありがとうございます。
    それでしたら納得です!!
    ということは「該当するレコードすべてにロック」の段階では
    一気にロックを獲得することができず、1行ずつロックを獲得して
    最終的に対象のレコードが全ロックになるのですが、
    その過程でロックが競合してしまうことになるんですね。
    あとから気づいたことですが、pg_lockのlock_typeがrerationなのが少し気になりますが…

    ちなみに更新コストは高いです。
    純正のストリーミングレプリケーションを「完全同期型」で構築し、
    pgpoolIIで分散構成になっておりますので。

    スレッドの趣旨としてはもう打ち切らないとですが、もう一つ疑問があります。
    この減少はPostgreSQL特有でしょうか?
    MySQLでも起きうることでしょうか?
    技術的には起こっても仕方がない、というより防ぎようがない気もするのですが…
    PostgreSQLは社内で私しか推してなくて、だったらMySQLでいいじゃんって言われてしまうと切ないのです…

    キャンセル

  • 2014/11/21 11:07

    デッドロック自体はどのRDBMSでも発生すると思います。機能として、デッドロック検知でロールバックする物があるはずなので、ロールバックしたら一定時間後にリトライするような方針もあるのではないでしょうか?

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.23%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る