Hi,
On 2022-08-21 17:15:01 -0400, Tom Lane wrote:
> I tried to duplicate this behavior locally (on RHEL8) and got something
> interesting. After increasing the server's max_connections to 1000,
> I can do
>
> $ pgbench -S -c 200 -j 100 -t 100 bench
>
> and it goes through fine. But:
>
> $ pgbench -S -c 200 -j 200 -t 100 bench
> pgbench (16devel)
> starting vacuum...end.
> pgbench: error: connection to server on socket "/tmp/.s.PGSQL.5440" failed: Resource temporarily unavailable
> Is the server running locally and accepting connections on that socket?
> pgbench: error: could not create connection for client 154
>
> So whatever is triggering this has nothing to do with the server,
> but with how many threads are created inside pgbench. I notice
> also that sometimes it works, making it seem like possibly a race
> condition. Either that or there's some limitation on how fast
> threads within a process can open sockets.
I think it's more likely to be caused by the net.core.somaxconn sysctl
limiting the size of the listen backlog. The threads part just influences the
speed at which new connections are made, and thus how quickly the backlog is
filled.
Do you get the same behaviour if you set net.core.somaxconn to higher than the
number of connections? IIRC you need to restart postgres for it to take
effect.
Greetings,
Andres Freund
