[pgcluster: 892] Re: pgbench で固まってしまいます

[a.mitani ＠ sra-europe.com]

浅羽さん，こんにちは．

1.3まではご指摘の通りです．
1.5ではネステッド・トランザクションのおかげで事情が更に複雑化しております．

これはもう，ロック管理の方法を根本的に見直すしかないと思っており，方法を模索
中です．
どのロックが先に解除されるか，ロックされた時点では判断できないのでキューイン
グするのは解決方法になりませんし，レプリケーションサーバ側からコントロールで
きない問題なのでClusterDB側に何らかの仕掛けが必要になります．
いっそのことセマフォをシェアしたらどうだろう，
と思ったのがPGCluster-IIの発想の発端です．

PGCluster-IIのプロトタイプで，セマフォと共有メモリを共有して（ストレージを共
有すれば）動くことが判りましたので，これを1.5に付け加えようかと思っています．

（何か相当遅くなりそうですが）

>
> From: a.mitani ＠ sra-europe.com
> Subject: [pgcluster: 888] Re: pgbench で固まってしまいます
> Date: Thu, 13 Jul 2006 12:18:58 +0200 (CEST)
>
>> > pgbenchでコネクション数を増やすとレプリケーションの処理が固まってしまうので
>> > す。
>> > だいたい１０ぐらいになるとそのままフリーズしてしまいます。
>> これは判っている問題なのですが，今のところ解決方法がありません．
>>
>> pgbenchはシングルプロセスのベンチマークツールで，デフォルトでは1トランザクショ
>> ン内で3つのUPDATEと１つのINSERT,１つのSELECTを発行しています．
>> デフォルトの設定では，３つのUPDATEのうち１つが同一レコードに更新をかけるため
>> ロックが発生します．レプリケーションをしない状態では上手くロック待ちができる
>> ようなのですが，レプリケーションを絡めるとロックが発生します．
>> pgbenchがシングルプロセスのため，１つでもロックが発生すると，次のクエリーが
>> 送られないため，固まります．
>
> 1.5.x のソースコードを見たことがないので検討違いのことを書いているかも
> しれませんが、これは pgbench がシングルプロセスだからデッドロックが発
> 生する、という問題ではありません。pgbench は非同期問い合わせを行うので、
> 本来であれば、ロック待ちが発生しても、デッドロック状態にはならないはず
> です。
>
> では、なぜ PGCluster でデッドロックが発生するかというと、PostgreSQL の
> 行ロック獲得アルゴリズムが原因になります。PostgreSQL では、行ロックを
> すでに獲得しているトランザクションがあると、他のトランザクションは待た
> されます。これは普通の挙動ですね。で、行ロックを持っているトランザクショ
> ンが終了すると、一斉に複数のクライアントが行ロックを奪いにいきます。こ
> こにレースコンディションが存在し、次にどのクライアントがロックを獲得す
> るかわからない状況になります。
>
> 1 つの DB サーバであれば、そんなに問題がないのですが、複数台が常に同期
> をとらないとなると、これは非常にまずいのです。何故かというと、各サーバ
> 上で異なるクライアントがロックを取る可能性があり、ロック獲得状況に不整
> 合が生じるためです。そのため、デッドロックが発生しています。
>
> このデッドロックが発生する条件は調べた限りでは、
>
>   - トランザクション隔離レベルが read committed
>   - 同じ行に対して 3 クライアント以上がロックを獲得しに行く
>
> です。pgbench で -c 2 の場合は、デッドロックしないのを確認できるかと思
> います。
>
> この問題はテーブルロック(SHARE ROW EXCLUSIVE)を先に獲得することで回避
> することができます。ちなみに、1.0.x では行ロックを獲得するようなクエリ
> は自動的にテーブルロックを獲得するオプションがあります。
>
>
>> pgbenchをマルチプロセスにしたpgcbenchというものはPGClusterでは用意しています
>> ので，こちらを使ってもらえれば，ベンチマークを計ることは可能です．
>> お試しください．
>
> pgcbench がなぜ動くかについても以前調べてみましたが、pgbench が発行す
> るクエリと微妙に異なり、複数のクライアントが同時に UPDATE するようなク
> エリが無くなっていました。
>
> --
> Yoshiyuki Asaba
> y-asaba ＠ sraoss.co.jp
>