<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hello Bo,</div><br><div class="gmail_default" style="font-family:tahoma,sans-serif">In our environment: <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">reserved_connections=0</div><div class="gmail_default" style="font-family:tahoma,sans-serif">listen_backlog_multiplier=2</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">So, if I understand correctly, we have 2 different problematic cases:</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">(1) a client silently disappears (doesn't properly close the connection): In this case, setting `child_idle_limit` to a non-zero value (say 15min) could mitigate the problem, and eventually the child worker will again be available to handle an incoming connection.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">(2) a server-side child process crashes: In this case, Pgpool still keeps a dangling reference to this process, and if some client is routed there will get a "sorry, too many clients" error. As for now, this problem cannot be mitigated unless the (parent) Pgpool process is restarted. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">One more question: <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">What can make a child process crash? (well, I mean, what are the most common reasons for that).</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Does this crash leave any trace (that I should search for) in Pgpool's error log? Does parent Pgpool get notified on this (e.g. via waitpid or SIGCHLD)?<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Best regards, Michail<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 13, 2021 at 10:10 AM Bo Peng <<a href="mailto:pengbo@sraoss.co.jp">pengbo@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I could reproduce this "sorry, too many clients" issue, <br>
even if reserved_connections=0 and pgpool child processes are available.<br>
<br>
The cause is that the pgpool child process connected by client is terminated unexpectedly.<br>
After that, if client connects to that terminated child process,<br>
"sorry, too many clients" error occurs.<br>
<br>
So far, the only workaround is to restart pgpool.<br>
We are considering a solution to avoid the problem.<br>
<br>
Regards,<br>
<br>
> Hello,<br>
> <br>
> I want to make sure if the message "sorry, too many clients" is issued by Pgpool,<br>
> because Pgpool-II issues "sorry, too many clients" messages, <br>
> only when reserved_connections is a non-zero value.<br>
> What is the setting of "reserved_connections"?<br>
>  <br>
> > I will  try `client_idle_limit` parameter.<br>
> > I was reluctant to use it because some clients probably won't like it (but<br>
> > it may be easier to fix it client-side).<br>
> > <br>
> > I have a basic question: how can I detect leaked (occupied and not reused)<br>
> > connection slots?<br>
> > Can `pcp_proc_info --all` provide some meaningful information in this<br>
> > direction?<br>
> <br>
> You can use pcp_proc_info command to confirm the used (occupied) connections.<br>
> However, the "not resued" connection is due to your application.<br>
> You may need to find out the reason why application doesn't use the pooled<br>
> connections on application side.<br>
> <br>
> For example, <br>
> application processes terminated unexpectedly, but the connections remained on pgpool side.<br>
> <br>
> BTW, in the coming major version 4.3, pcp_proc_info command is able to<br>
> display more useful information such as:<br>
> - connection created timestamp<br>
> - connection created timestamp<br>
> - last client connected timestamp<br>
> - client idle duration (sec) <br>
> - last client disconnected timestamp<br>
> - connection-reuse counter<br>
> - etc.<br>
> <br>
> > Let M be the maximum number (worst case) of connections that clients can<br>
> > ask for.<br>
> > Let N be the number of per-backend connection slots (= num_init_children *<br>
> > max_pool) available in Pgpool.<br>
> > Of course: M < N.<br>
> > <br>
> > I can measure the number m of occupied slots (say for backend #0) as:<br>
> > m=$(pcp_proc_info ${pcp_opts} --all | grep '0$' | grep -c -v '^[[:space:]]')<br>
> > <br>
> > If m grows greater than M for some "steady" period of time (say for over<br>
> > 10min),<br>
> > can I interpret this as a sign of leaked (non-reused) connection slots ?<br>
> <br>
> I think m could not be greater than M,<br>
> because M is the max connections that client can ask for.<br>
> <br>
>   M = num_init_children - reserved_connections<br>
> <br>
> Regrads,<br>
>  <br>
> > On Tue, Oct 12, 2021 at 7:10 AM Bo Peng <<a href="mailto:pengbo@sraoss.co.jp" target="_blank">pengbo@sraoss.co.jp</a>> wrote:<br>
> > <br>
> > > Hello,<br>
> > ><br>
> > > > Hello PgPool<br>
> > > ><br>
> > > > We are using PgPool 4.2.4 (from Alpine 3.13) as the frontend of a<br>
> > > > master/standby PostgreSQL 10.14 cluster (2 synchronous standbys in<br>
> > > > streaming replication mode). PgPool is operating as a load balancer and a<br>
> > > > connection pool.<br>
> > > ><br>
> > > > PgPool forks 90 pool workers (num_init_children=90, max_pool=2). All<br>
> > > > PostgreSQL backend servers are configured properly to accept a maximum of<br>
> > > > 190 connections (so, num_init_children * max_pool is below this maximum<br>
> > > > with a safety margin of 10).<br>
> > > ><br>
> > > > The relevant (pool-specific) part of the configuration is:<br>
> > > > num_init_children = 90<br>
> > > > max_pool = 2<br>
> > > > child_life_time = 5min<br>
> > > > child_max_connections = 0<br>
> > > > connection_life_time = 0<br>
> > > > client_idle_limit = 0<br>
> > > ><br>
> > > > After a while (5-10 days of operation), we face several errors of the<br>
> > > type<br>
> > > > of "Sorry, too many clients".  These errors are not originating from a<br>
> > > > PostgreSQL backend (error logs are completely clear and pg_stat_activity<br>
> > > > shows no more than 140 (from 190) active connections).<br>
> > > ><br>
> > > > This problem has been around for some time now, and we have to resort to<br>
> > > > restarting the entire PgPool service. Of course, this is not a perfect<br>
> > > > solution because it disrupts some database clients (so, we also have to<br>
> > > > cascade those restarts to some other services, and so on).<br>
> > > ><br>
> > > > The majority of database clients are connecting from a Hikari pool (Java<br>
> > > > Spring/Boot) which creates long-standing connections (i.e. not one<br>
> > > > per-transaction).<br>
> > > ><br>
> > > > Any light on this issue is highly appreciated!<br>
> > ><br>
> > > The connections hasn't been resued?<br>
> > > Because you are using connection pooling between client and pgpool,<br>
> > > I think the cached connections should be reused.<br>
> > ><br>
> > > You may need to configure "client_idle_limit" paramater<br>
> > > to prevent the Pgpool-II child processes from being occupied for long time<br>
> > > by broken connections.<br>
> > ><br>
> > ><br>
> > > <a href="https://www.pgpool.net/docs/latest/en/html/runtime-config-connection-pooling.html#GUC-CLIENT-IDLE-LIMIT" rel="noreferrer" target="_blank">https://www.pgpool.net/docs/latest/en/html/runtime-config-connection-pooling.html#GUC-CLIENT-IDLE-LIMIT</a><br>
> > ><br>
> > > --<br>
> > > Bo Peng <<a href="mailto:pengbo@sraoss.co.jp" target="_blank">pengbo@sraoss.co.jp</a>><br>
> > > SRA OSS, Inc. Japan<br>
> > > <a href="http://www.sraoss.co.jp/" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/</a><br>
> > ><br>
> <br>
> <br>
> -- <br>
> Bo Peng <<a href="mailto:pengbo@sraoss.co.jp" target="_blank">pengbo@sraoss.co.jp</a>><br>
> SRA OSS, Inc. Japan<br>
> <a href="http://www.sraoss.co.jp/" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/</a><br>
> _______________________________________________<br>
> pgpool-general mailing list<br>
> <a href="mailto:pgpool-general@pgpool.net" target="_blank">pgpool-general@pgpool.net</a><br>
> <a href="http://www.pgpool.net/mailman/listinfo/pgpool-general" rel="noreferrer" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-general</a><br>
<br>
<br>
-- <br>
Bo Peng <<a href="mailto:pengbo@sraoss.co.jp" target="_blank">pengbo@sraoss.co.jp</a>><br>
SRA OSS, Inc. Japan<br>
<a href="http://www.sraoss.co.jp/" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/</a><br>
</blockquote></div>