Horton

Re: pgbench: could not connect to server: Resource temporarily unavailable

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Kevin McKibbin <kevinmckibbin123@gmail.com>
Cc: pgsql-performance@lists.postgresql.org
Date: 2022-08-21T20:18:47Z
Lists: pgsql-performance 
On 2022-08-20 Sa 23:20, Tom Lane wrote:
> Kevin McKibbin <kevinmckibbin123@gmail.com> writes:
>> What's limiting my DB from allowing more connections?
>> This is a sample of the output I'm getting, which repeats the error 52
>> times (one for each failed connection)
>> -bash-4.2$ pgbench -c 200 -j 200 -t 100 benchy
>> ...
>> connection to database "benchy" failed:
>> could not connect to server: Resource temporarily unavailable
>>         Is the server running locally and accepting
>>         connections on Unix domain socket
>> "/var/run/postgresql/.s.PGSQL.5432"?
> This is apparently a client-side failure not a server-side failure
> (you could confirm that by seeing whether any corresponding
> failure shows up in the postmaster log).  That means that the
> kernel wouldn't honor pgbench's attempt to open a connection,
> which implies you haven't provisioned enough networking resources
> to support the number of connections you want.  Since you haven't
> mentioned what platform this is on, it's impossible to say more
> than that --- but it doesn't look like Postgres configuration
> settings are at issue at all.



The first question in my mind from the above is where this postgres
instance is actually listening. Is it really /var/run/postgresql? Its
postmaster.pid will tell you. I have often seen client programs pick up
a system libpq which is compiled with a different default socket directory.



cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Commits

  1. Doc: document possible need to raise kernel's somaxconn limit.

  2. Doc: prefer sysctl to /proc/sys in docs and comments.

  3. Remove our artificial PG_SOMAXCONN limit on listen queue length.

  4. Instead of believing SOMAXCONN from the system header files (which is