Horton

connection establishment versus parallel workers

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: pgsql-hackers@postgresql.org
Cc: thomas.munro@gmail.com
Date: 2024-12-11T20:42:58Z
Lists: pgsql-hackers

Attachments

My team recently received a report about connection establishment times
increasing substantially from v16 onwards.  Upon further investigation,
this seems to have something to do with commit 7389aad (which moved a lot
of postmaster code out of signal handlers) in conjunction with workloads
that generate many parallel workers.  I've attached a set of reproduction
steps.  The issue seems to be worst on larger machines (e.g., r8g.48xlarge,
r5.24xlarge) when max_parallel_workers/max_worker_process is set very high
(>= 48).

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.

-- 
nathan

Commits

  1. Fix latch event policy that hid socket events.

  2. Teach WaitEventSetWait() to report multiple events on Windows.

  3. Process pending postmaster work before connections.

  4. Use WaitEventSet API for postmaster's event loop.

  5. Replace buffer I/O locks with condition variables.