<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hello Bo, <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks for your quick response</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><div class="gmail_default" style="font-family:tahoma,sans-serif">I will  try `client_idle_limit` parameter.  <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I was reluctant to use it because some clients probably won't like it (but it may be easier to fix it client-side).<br></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I have a basic question: how can I detect leaked (occupied and not reused) connection slots? <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Can `pcp_proc_info --all` provide some meaningful information in this direction?<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Let M be the maximum number (worst case) of connections that clients can ask for. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Let N be the number of per-backend connection slots (= num_init_children * max_pool) available in Pgpool.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Of course: M < N.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I can measure the number m of occupied slots (say for backend #0) as:</div><div class="gmail_default"><span style="background-color:rgb(207,226,243)"><span style="font-family:monospace">m=$(pcp_proc_info ${pcp_opts} --all | grep '0$' | grep -c -v '^[[:space:]]')</span></span></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">If m grows greater than M for some "steady" period of time (say for over 10min), <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">can I interpret this as a sign of leaked (non-reused) connection slots ? <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Kind regards, Michail Alexakis<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 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 Tue, Oct 12, 2021 at 7: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>
> 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 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>
  <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>
</blockquote></div>