[pgpool-general-jp: 302] Re: Pgpoolのパフォーマンスについて

[Nobuaki Inamura]

稲村と申します。お世話になります。

浅羽様、ありがとうございます。

Yoshiyuki Asaba さんは書きました:
> 改善されるかわからないですが、バッファリングしているところで気になると
> ころがあったので、添付のパッチを適用するといかがでしょうか？
ありがとうございます。
恥ずかしい質問ですが、debianパッケージのソース(3.1)に当てる、ということですよね？
そうすると、パッケージで管理している意味があまりなくなってしまうので、おそらくソースを
コンパイルして使っても同じことになりますよね。
一先ず3.1のソースを引っ張ってきてやってみます。


ちなみにこのパッチは、1系の最新版、3.4.1には適用されているものですか？

といいますのも、Postgresのパフォーマンスを調べていて、debianパッケージは遅いと書いてあったので、
最初のメールの後に、ためしにpgpool3.4.1のソースをコンパイルして動かしてみました。
（pgpool2にしたかったのですが、ライブラリのバージョンがあわなくてコンパイルできませんでした。）
そうすると、今まで直DBの6割程度の性能しか出なかったのが、8割程度出るようになりました。
（単純なSELECT文の場合）

で、pgbenchを実行したところ、たとえばクライアント10、トランザクション10で実行してみると

tps = 86.105648 (including connections establishing)
tps = 135.689997 (excluding connections establishing)

といった具合に、接続の確立に要した時間を含める／含めないを比べた際にかなりの差が出ていました。
因みにPgpoolを通さないと、

tps = 136.591309 (including connections establishing)
tps = 141.839344 (excluding connections establishing)

と、そこまで大きな差がでないので、接続するオーバーヘッドのロスがかなり大きいなあという
印象でした。それを実証するため、接続は増やさず、トランザクションを増やしてみました。

Pgpoolを通して、今度はトランザクションを50に増やしてみると
tps = 126.869163 (including connections establishing)
tps = 141.199421 (excluding connections establishing)
と、差が減っていました。
やはり接続時にかなりの時間のロスがあるような感じがします。

（参考）
Pgpool上から、SELECTのみのオプションをつけた場合、（-c 10 -t 10　オプション)
tps = 210.099482 (including connections establishing)
tps = 2698.035830 (excluding connections establishing)

PgpoolなしでSELECTのみ
tps = 1247.271593 (including connections establishing)
tps = 1924.631433 (excluding connections establishing)

因みに、Pgpoolはレプリケーションしてはいますが、負荷分散はしていません。
セカンダリのマシンはマスタとほぼ同一のスペックを持つマシンです。
ネットワーク的にはHUB1つはさんでいます。

実行は、postgresを5433に、Pgpoolを5432で待機させ、マスタのマシン上で、
Pool経由は
/usr/lib/postgresql/8.1/bin/pgbench -c 10 -t 10 -h 127.0.0.1 -p 5432 bench
直接は
/usr/lib/postgresql/8.1/bin/pgbench -c 10 -t 10 -p 5433 bench
というコマンドで実行しました。

接続のロスは正常な値なのでしょうか？

お手数をおかけいたします。よろしくお願いいたします。


-- 
Nobuaki Inamura : inamuran36 ＠ mahikari.or.jp