[pgpool-general-jp: 1644] Re: pgpool-IIの処理性能について

[egashira.yusuke ＠ fujitsu.com]

石井様、北村様

江頭と申します。
いつもお世話になっております。
# ML投稿がはじかれてしまったので再送いたします。

北村様の事象と類似しているものをこちらでも検知し、
調査していたところだったため、横から失礼させていただきます。

私も同様の環境(ストリーミングレプリケーション環境、ロードバランス無効)で
SQL実行ごとにスタンバイサーバとの通信待ち合わせが発生する事象の調査を行っていたのですが、
どうもクライアントが拡張問い合わせプロトコルを使用してSQLを実行した場合に
Pgpoolから Sync のメッセージがプライマリとスタンバイの両方に送信され、かつ、
両方のサーバからの ReadyForQueryメッセージを待機するようです。

具体的には src/protocol/pool_proto_modules.c の
ProcessFrontendResponse 関数でSyncメッセージを扱う場合のみ
プライマリとスタンバイの両方に対して同期的にSyncメッセージを送信し、返事を待つようです。

ただ、Pgpool-IIのドキュメントやFAQにはこのように
「拡張問い合わせプロトコルを用いるとSyncでスタンバイ待ち合わせが発生する」ことは記載がないものの、
待ち合わせの処理自体は過去のコミット 8640abfc41ff06b1e6d31315239292f4d3d4191d で
問題の修正のために導入された処理のようにも見えますので、
この挙動が意図された動作かどうかがわかりませんでした。

恐れ入りますが、この挙動が意図されたものかどうか、
意図されたものであれば回避する方法を教えていただければ幸いです。
# master_slave_sub_mode が stream モードの場合のみ両方に飛ぶようなので、
# slony モードを指定すれば回避可能とも思いましたが、
# ストリーミングレプリケーションを使っている以上、他の処理に影響しそうなので不適切と考えています。


なお、Pgpool-II 4.0.2、4.0.7、 4.1.4 の各バージョンでこの挙動となることは確認しました。
確認時の主なパラメータは以下です。
- master_slave_mode = on
- master_slave_sub_mode = 'stream'
- sr_check_period = 0
- connection_cache = on
- load_balance_mode = off
- health_check_period = 0

以上、よろしくお願いいたします。

-------------------------------------------------
富士通(株)
データマネジメント事業部 第二開発部
江頭　勇佑 (Egashira Yusuke)
egashira.yusuke ＠ jp.fujitsu.com
TEL 外線：078-414-8597
-------------------------------------------------