On Thu, Dec 12, 2024 at 11:36 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Thu, Dec 12, 2024 at 9:43 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> > Our theory is that commit 7389aad (and follow-ups like commit 239b175) made
> > parallel worker processing much more responsive to the point of contending
> > with incoming connections, and that before this change, the kernel balanced
> > the execution of the signal handlers and ServerLoop() to prevent this. I
> > don't have a concrete proposal yet, but I thought it was still worth
> > starting a discussion. TBH I'm not sure we really need to do anything
> > since this arguably comes down to a trade-off between connection and worker
> > responsiveness.
>
> One factor is:
>
> * Check if the latch is set already. If so, leave the loop
> * immediately, avoid blocking again. We don't attempt to report any
> * other events that might also be satisfied.
Here's an experimental patch to try changing that policy. It improves
the connection times on my small computer with your test, but I doubt
I'm seeing the real issue. But in theory, assuming a backlog of
connections and workers to start, I think each server loop should be
able to accept and fork one client backend, and fork up to 100
(MAX_BGWORKERS_TO_LAUNCH) background workers.