Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Kevin McKibbin <kevinmckibbin123@gmail.com>, pgsql-performance@lists.postgresql.org
Date: 2022-08-21T22:55:31Z
Lists: pgsql-performance 
Thomas Munro <thomas.munro@gmail.com> writes:
> If it's something like that, maybe increasing
> /proc/sys/net/core/somaxconn would help?  I think older kernels only
> had 128 here.

Bingo!  I see

$ cat /proc/sys/net/core/somaxconn
128

by default, which is right about where the problem starts.  After

$ sudo sh -c 'echo 1000 >/proc/sys/net/core/somaxconn'

*and restarting the PG server*, I can do a lot more threads without
a problem.  Evidently, the server's socket's listen queue length
is fixed at creation and adjusting the kernel limit won't immediately
change it.

So what we've got is that EAGAIN from connect() on a Unix socket can
mean "listen queue overflow" and the kernel won't treat that as a
nonblock-waitable condition.  Still seems like a kernel bug perhaps,
or at least a misfeature.

Not sure what I think at this point about making libpq retry after
EAGAIN.  It would make sense for this particular undocumented use
of EAGAIN, but I'm worried about others, especially the documented
reason.  On the whole I'm inclined to leave the code alone;
but is there sufficient reason to add something about adjusting
somaxconn to our documentation?

			regards, tom lane

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