<div dir="ltr">Thank you Tatsuo for the info. If I set connection_cache = false, does that turn off *all* connection pooling features?<br><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">--Cal<br><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 5, 2014 at 4:35 PM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Hi everyone,<br>
><br>
> In playing with some timeout settings with some real-world live traffic, I<br>
> noticed that pgpool keeps a lot of server-side idle connections open. I<br>
> started with a child_life_time of 30 seconds, and it quickly consumed up<br>
> all of my num_init_children setting (32) on the postgres server. I'd like<br>
> to minimize the number of connections left open (and idle) on the postgres<br>
> server.<br>
<br>
</span>Yes, that's the effect of connection pooling of pgpool-II. If you<br>
don't like this, you can turn it off by setting connection_cache off.<br>
<span class=""><br>
> When I dropped the child_life_time down to 5 seconds, it reduced the idle<br>
> connections significantly.<br>
<br>
</span>Yes, becuase each pgpool-II child is responsible for keeping the<br>
connection pooling in their process space.<br>
<span class=""><br>
> While that effectively solves my problem, I'm<br>
> wondering what algorithm is used to select a server pool slot when a new<br>
> client connects. As I was watching it, it seems like an LRU algorithm,<br>
> picking the server side slot with the largest idle time.<br>
<br>
</span>No. pgpool-II employes pre-fork model, which means multiple child<br>
process are forked and are waiting for connect(2) request comes from<br>
client. If the request arrives to the port pgpool-II is listening on,<br>
the kernel selects one of the child process and let it process. I<br>
don't know what algorithm is used within the kernel process. Maybe<br>
it's URL, maybe not.<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>
<span class=""><br>
> If that's the<br>
> case, I think I would prefer it to pick the server side slot with the<br>
</span>> *smallest* idle time. The pool should then shrink to the minimal number of<br>
<div class="HOEnZb"><div class="h5">> server-side connection slots required to handle the current client-side<br>
> load. Then to account for burst activity, the idle time could be upped to<br>
> keep a small amount of extra slots for burst capacity.<br>
><br>
> The way it seems now, I have to shorten the idle timeout to something very<br>
> short in order to keep from overrunning my connection limits on the<br>
> postgres server.<br>
><br>
> Does any of this seem correct, or am I way off base here?<br>
><br>
> Thank you!<br>
><br>
> --Cal<br>
</div></div></blockquote></div><br></div></div>