<div dir="ltr"><div><div>Still confused by these results. <br><br>I turned connection caching back on in pgpool and used the -C option to pgbench with the following result. tps seems on par with just doing a direct connection to the master, but only if the connection establishment is excluded. Included, it&#39;s pretty horrible.<br><br>kfiske@pgpool-base:/etc/pgpool2$ pgbench -c 20 -j 10 -T 300 -S -C pgbench<br>Password: <br>starting vacuum...end.<br>transaction type: SELECT only<br>scaling factor: 1000<br>query mode: simple<br>number of clients: 20<br>number of threads: 10<br>duration: 300 s<br>number of transactions actually processed: 2217927<br>latency average: 2.705 ms<br>tps = 7393.042019 (including connections establishing)<br>tps = 119967.718643 (excluding connections establishing)<br><br></div>Running again without -C and back to the performance being halved<br><br>kfiske@pgpool-base:/etc/pgpool2$ pgbench -c 20 -j 10 -T 300 -S pgbench<br>Password: <br>starting vacuum...end.<br>transaction type: SELECT only<br>scaling factor: 1000<br>query mode: simple<br>number of clients: 20<br>number of threads: 10<br>duration: 300 s<br>number of transactions actually processed: 15227370<br>latency average: 0.394 ms<br>tps = 50757.799330 (including connections establishing)<br>tps = 50760.275039 (excluding connections establishing)<br><br></div><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Keith Fiske<br>Database Administrator<br>OmniTI Computer Consulting, Inc.<br><a href="http://www.keithf4.com" target="_blank">http://www.keithf4.com</a></div></div>
<br><div class="gmail_quote">On Mon, Jan 19, 2015 at 6:05 PM, Tatsuo Ishii <span dir="ltr">&lt;<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you want to test the effect of connection caching, you should turn<br>
on -C option of pgbench.<br>
<br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
<div class="HOEnZb"><div class="h5"><br>
&gt; Evaluating pgpool for a client as a load balancer and running into some<br>
&gt; unexpected performance degradation. Using pg_bench, read-only selects are<br>
&gt; going half as fast through pgpool as they are going directly to the master<br>
&gt; system. Does not seem to be a network issue between the pgpool server and<br>
&gt; the databases since connecting directly to either the master or the slave<br>
&gt; from the pgpool server works fine.<br>
&gt;<br>
&gt; I saw this issue on the list archive<br>
&gt; <a href="http://www.sraoss.jp/pipermail/pgpool-general/2015-January/003438.html" target="_blank">http://www.sraoss.jp/pipermail/pgpool-general/2015-January/003438.html</a><br>
&gt; but I&#39;m not in a position right now to be testing a patched version on<br>
&gt; their systems. I tried turning off connection caching and doing the kernel<br>
&gt; tuning as mentioned in that email. The first kernel tuning parameter<br>
&gt; doesn&#39;t seem to exist for this system (Ubuntu 12.04) and changing the other<br>
&gt; two didn&#39;t seem to make any difference.<br>
&gt;<br>
&gt; If anyone has any other suggestions for what to look at, I&#39;d appreciate it.<br>
&gt; The only thing pgpool is being used for is load balancing and connection<br>
&gt; pooling. All other options are turned off.<br>
&gt;<br>
&gt; SELECT directly from master from the pgpool server but not using pgpool<br>
&gt; kfiske@pgpool-base:/etc/pgpool2$ pgbench -h db01 -c 20 -j 10 -T 300 -S<br>
&gt; pgbench<br>
&gt; Password:<br>
&gt; starting vacuum...end.<br>
&gt; transaction type: SELECT only<br>
&gt; scaling factor: 1000<br>
&gt; query mode: simple<br>
&gt; number of clients: 20<br>
&gt; number of threads: 10<br>
&gt; duration: 300 s<br>
&gt; number of transactions actually processed: 33780221<br>
&gt; latency average: 0.178 ms<br>
&gt; tps = 112600.544120 (including connections establishing)<br>
&gt; tps = 112610.109694 (excluding connections establishing)<br>
&gt;<br>
&gt;<br>
&gt; SELECT directly from slave from the pgpool server but not using pgpool<br>
&gt; kfiske@pgpool-base:/etc/pgpool2$ pgbench -h db02 -c 20 -j 10 -T 300 -S<br>
&gt; pgbench -n<br>
&gt; Password:<br>
&gt; transaction type: SELECT only<br>
&gt; scaling factor: 1000<br>
&gt; query mode: simple<br>
&gt; number of clients: 20<br>
&gt; number of threads: 10<br>
&gt; duration: 300 s<br>
&gt; number of transactions actually processed: 30087965<br>
&gt; latency average: 0.199 ms<br>
&gt; tps = 100293.060878 (including connections establishing)<br>
&gt; tps = 100302.790535 (excluding connections establishing)<br>
&gt;<br>
&gt;<br>
&gt; SELECT only from pgpool (to ensure load-balancing works)<br>
&gt; kfiske@pgpool-base:/etc/pgpool2$ pgbench -c 20 -j 10 -T 300 -S pgbench<br>
&gt; Password:<br>
&gt; starting vacuum...end.<br>
&gt; transaction type: SELECT only<br>
&gt; scaling factor: 1000<br>
&gt; query mode: simple<br>
&gt; number of clients: 20<br>
&gt; number of threads: 10<br>
&gt; duration: 300 s<br>
&gt; number of transactions actually processed: 14781236<br>
&gt; latency average: 0.406 ms<br>
&gt; tps = 49270.616847 (including connections establishing)<br>
&gt; tps = 49273.323274 (excluding connections establishing)<br>
&gt;<br>
&gt; --<br>
&gt; Keith Fiske<br>
&gt; Database Administrator<br>
&gt; OmniTI Computer Consulting, Inc.<br>
&gt; <a href="http://www.keithf4.com" target="_blank">http://www.keithf4.com</a><br>
</div></div></blockquote></div><br></div>