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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Kevin McKibbin <kevinmckibbin123(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: pgbench: could not connect to server: Resource temporarily unavailable
Date: 2022-08-22 00:20:37
Message-ID: 84184.1661127637@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Yeah retrying doesn't seem that nice. +1 for a bit of documentation,
> which I guess belongs in the server tuning part where we talk about
> sysctls, perhaps with a link somewhere near max_connections? More
> recent Linux kernels bumped it to 4096 by default so I doubt it'll
> come up much in the future, though.

Hmm. It'll be awhile till the 128 default disappears entirely
though, especially if assorted BSDen use that too. Probably
worth the trouble to document.

> Note that we also call listen()
> with a backlog value capped to our own PG_SOMAXCONN which is 1000. I
> doubt many people benchmark with higher numbers of connections but
> it'd be nicer if it worked when you do...

Actually it's 10000. Still, I wonder if we couldn't just remove
that limit now that we've desupported a bunch of stone-age kernels.
It's hard to believe any modern kernel can't defend itself against
silly listen-queue requests.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Thomas Munro 2022-08-22 02:02:50 Re: pgbench: could not connect to server: Resource temporarily unavailable
Previous Message Thomas Munro 2022-08-21 23:33:33 Re: pgbench: could not connect to server: Resource temporarily unavailable