<div dir="ltr">Good idea. <div><br></div><div>Do not forget to increase sysctl params like </div><div><div><br></div><div>net.core.somaxconn</div><div>net.core.netdev_max_backlog</div></div><div><br></div><div><br></div><div>
And more faster get socket stats (netstat -an[s] | wc -l)</div><div>cat /proc/net//sockstat<br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/18 Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> Hi pgpool hackers,<br>
><br>
> I would like to add new parameter "listen_backlog". This essentially<br>
> same as Apache's ListenBacklog parameter:<br>
><br>
> The second parameter of listen(2) system call.<br>
><br>
> As you might already know, pgpool accepts concurrent connections up to<br>
> num_init_children. Exceeding connections will be queued in kernel's<br>
> backlog queue. If the queue is long enough to accept a new connection,<br>
> the request from the client will be almost immediately accepted by<br>
> pgpool once existing client disconnects to pgpool. However, if the<br>
> queue is overflowed, the client might retry after 3 seconds or so, and<br>
> user thinks that pgpool's response is too bad. Or disconnected by<br>
> pgpool with "Connection to database "test" failed: could not connect<br>
> to server: Connection timed out".<br>
><br>
> The solution is, making the backlog parameter large enough for such<br>
> possible load. Currently the backlog is calculated by<br>
> num_init_children * 2. But this may not be large enough for certain<br>
> load. For the case, the new proposed parameter can set the listen()'s<br>
> backlog parameter longer than num_init_children * 2.<br>
><br>
> Here is an experiment I did to illustrate the effect of the<br>
> parameter(script attached).<br>
><br>
> I started pgpool with num_init_children = 2, and connected to it by<br>
> using 128 forked pgbench.<br>
> Each pgbench executes 100 read only queries.<br>
><br>
> pgbench -C -c 1 -n -S test;date)&<br>
><br>
> The pgpool server is a Linux box running kernel 3.4.68.<br>
><br>
> Stock pgpool-II 3.3.1, which set the backlog parameter to 4, took 1<br>
> minute and 7 seconds. And some requests failed with "Connection to<br>
> database "test" failed" error.<br>
<br>
</div></div>Please note that you will find something like:<br>
<br>
2357 times the listen queue of a socket overflowed<br>
<br>
by executing netstat -s in this case.<br>
<div class="im"><br>
> On the other hand if I set the backlog parameter to 1024, it took only<br>
> 15 seconds without any error.<br>
><br>
> Opinions?<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>_______________________________________________<br>
pgpool-hackers mailing list<br>
<a href="mailto:pgpool-hackers@pgpool.net">pgpool-hackers@pgpool.net</a><br>
<a href="http://www.pgpool.net/mailman/listinfo/pgpool-hackers" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-hackers</a><br>
</blockquote></div><br></div>