From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Bee.Lists" <bee.lists@gmail.com>
cc: Submit Postgresql Novice <pgsql-novice@postgresql.org>
Subject: Re: Connections Increasing Slowly
In-reply-to: <8A1234E2-D4C3-451F-8F60-901D0D5E0CA5@gmail.com>
References: <8A1234E2-D4C3-451F-8F60-901D0D5E0CA5@gmail.com>
Comments: In-reply-to "Bee.Lists" <bee.lists@gmail.com>
	message dated "Mon, 22 Jun 2020 15:43:09 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2088229.1592856708.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 22 Jun 2020 16:11:48 -0400
Message-ID: <2088230.1592856708@sss.pgh.pa.us>
Precedence: bulk

"Bee.Lists" <bee.lists@gmail.com> writes:
> Hi folks.  My PostgreSQL server has a growing number of connections.  =

> Currently it=E2=80=99s at 115.  max_connections set to 300.  It=E2=80=99=
s being accessed from public (web application), server cron once a day, an=
d two clients on the LAN, a handful of times a day.  =


> I=E2=80=99m a bit surprised that the connection pool isn=E2=80=99t purge=
d during this time.  =


Postgres doesn't really think that killing connections is part of its
charter.  (There is idle_in_transaction_session_timeout, but that's
there to guard against a specific performance issue, not to kill
non-misbehaving sessions.)

You should probably think about putting a connection pooler such as
pgbouncer in front of your server.  That's a better idea for lots of
low-resource-demand clients than giving them direct server connections.
And I think you're more likely to find features for killing idle
connections there, too.

Another idea, if you suspect that the idle connections are caused
by firewall timeouts or the like, is to enable more aggressive
TCP keepalive checking, to ensure the server notices if a client
isn't there at all anymore.  See the tcp_keepalives_* settings.

			regards, tom lane