Well, I guess the questions is - how do I optimize PG for a stream of very 
short life checks...
See below:

2020-04-02 11:05:37.010 CDTLOG:  connection received: host=10.64.72.157 
port=45799
2020-04-02 11:05:37.014 CDTLOG:  connection received: host=10.64.72.157 
port=45814
2020-04-02 11:05:37.014 CDTLOG:  connection received: host=10.64.72.157 
port=45813
2020-04-02 11:05:37.018 CDTFATAL:  sorry, too many clients already
2020-04-02 11:05:37.015 CDTLOG:  connection received: host=10.64.72.157 
port=45815
2020-04-02 11:05:37.015 CDTLOG:  connection received: host=10.64.72.157 
port=45817
2020-04-02 11:05:37.015 CDTLOG:  connection received: host=10.64.72.157 
port=45809
2020-04-02 11:05:37.015 CDTLOG:  connection received: host=10.64.72.157 
port=45818
2020-04-02 11:05:37.016 CDTLOG:  connection received: host=10.64.72.157 
port=45819
2020-04-02 11:05:37.021 CDTFATAL:  sorry, too many clients already
2020-04-02 11:05:37.021 CDTFATAL:  sorry, too many clients already
2020-04-02 11:05:37.021 CDTFATAL:  sorry, too many clients already
2020-04-02 11:05:37.021 CDTFATAL:  sorry, too many clients already
2020-04-02 11:05:37.021 CDTFATAL:  sorry, too many clients already
2020-04-02 11:05:37.022 CDTFATAL:  sorry, too many clients already
2020-04-02 11:05:37.022 CDTFATAL:  sorry, too many clients already
-----Original Message-----
From: Tom Lane <t...@sss.pgh.pa.us> 
Sent: Thursday, April 02, 2020 6:52 PM
To: Abraham, Danny <danny_abra...@bmc.com>
Cc: pgsql-gene...@postgresql.org
Subject: [EXTERNAL] Re: too many clients already

"Abraham, Danny" <danny_abra...@bmc.com> writes:
> Running on a big and stressed AIX platform and receiving lots of "CDTFATAL:  
> sorry, too many clients already"
> and transient difficulty to log in.
> Happens on all PG versions (Tested 9.5,10.4,11.5) Big installation: 
> max_connections is 1200,  shared_buffers is 2GB
> But .. select count(*) from pg_stat_activity   is only 66.

I'd be suspicious that there are a lot of clients stuck in connection startup 
(likely the authentication phase); those connections aren't going to show in 
pg_stat_activity until they finish connecting.  The "ps"
suggestion Adrian gave you would not show them either, because they're not 
going to say "idle".

Enabling log_connections and watching the postmaster log would help prove or 
disprove that theory.

                        regards, tom lane


Reply via email to