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

[Eiichiro ITANI]

反応遅くなってすみませんでした，猪谷です。

Yoshiyuki Asaba <y-asaba ＠ sraoss.co.jp> writes:

> 今回のパッチは、行ロックをテーブルロック(SHARE ROW EXCLUSIVE)に置き換
> えるということをやっています。これは、postgresql.conf の
> auto_lock_table = true の場合にこのような挙動になります。false にした
> 場合は依然として pgbench は固まります。

簡単に言えば、ロックの粒度を大きくしているので pgcluster でのデッドロッ
クは避けられるが、デメリットとして同一のテーブルの更新を伴う複数のトラ
ンザンクションが並行する場合に、大きくパフォーマンスが落ちる可能性があ
る、という理解でよろしいでしょうか?


今パッチを当てた 1.5 でテストをしておりますが、perl DBI なクライアント
からの処理を色々やっている最中に、レプリケーターがロックしてしまったよ
うです。具体的に何をやっておかしくなったのか把握できないので
(pgreplicate はデーモンモードで動かしているため、ログが取れていません)
改めて再現できないか調べております。

こちらの構成は

 c1 クラスタ1
 c2 クラスタ2
 r1 レプリケータ主
 l1 ロードバランサ、レプリケータ従

で、c1/c2 が Dual Xeon、r1/l1 が Xeon、いずれもHTTオフです。

クラスタでは auto_lock_table=true、レプリケータではResponse_Mode
reliable、クライアントは主に perl DBI を使ったcgi/fastcgi スクリプトで
した。

おかしくなった所で、psql を使って cgi/fastcgi が触っているのとは別の
DBクラスタに接続し、そこのテーブルへの INSERT を試みた所、INSERT が固まっ
てしまいました。C-c でクエリのキャンセルを行おうとしてもプロンプトが返っ
てこず、しばらく待ってもダメだったので、主/従のレプリケータを終了し、レ
プリケータの再起動を行いました。

このときにどうやら、perl クライアントがまだ繋がっていたらしく、クラス
タ1/2のログにはクライアントの切断メッセージ、及び redo ログが出力され
ました。

ですので、本当にレプリケータがロックしたのか、他のクライアントが処理中
でそれの完了まで待たされていたのかはちょっと不明です。再現した場合、ま
た報告させていただきます。

現在レプリケータを一台にしてデバッグモードにし、perl DBI 接続時に
pg_server_prepare = 0 の設定で試験してもらっています。


ところで、レプリケータのカスケード設定なんですが、これは主レプリケータ
の pgreplicate.conf に、Replcate_Server_Infoを書く物なのでしょうか。コ
メントを読むとどっちにも取れる(カスケード上位ならば設定を書く | カスケー
ド上位サーバの場所を書く)ので、混乱していました。

どうやら「カスケード上位ならば設定を書く」という意味らしいと思うのです
が、間違ってますでしょうか?


長々とすみません。もう少し現象が掴めたら改めてポストさせていただきます。

--
  いたに えいいちろう