Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tLTY3-00F1QN-8S for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Dec 2024 20:43:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tLTY0-002Jth-K2 for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Dec 2024 20:43:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tLTY0-002JtZ-9l for pgsql-hackers@lists.postgresql.org; Wed, 11 Dec 2024 20:43:05 +0000 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tLTXy-002L8h-Pb for pgsql-hackers@postgresql.org; Wed, 11 Dec 2024 20:43:04 +0000 Received: by mail-io1-xd2a.google.com with SMTP id ca18e2360f4ac-844d555491eso20912539f.0 for ; Wed, 11 Dec 2024 12:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733949781; x=1734554581; darn=postgresql.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=yB9p36p4lL+pivp3/7EBXNjAhc1hmVNVRSf9rtYP14I=; b=et7TZMrztj8XIr/W+XLiGERLVCzwDpgCHG+ui4F3xNs+YSsfF8mGyPNhUHbTKJroDe oCj+jwFfHrQKyxR7pbKj/d19tcFeW8b9O4jH5PBA+QAKqK1HeEhZnYNsUQWMaABMxLld 0d+d/KBTshuP++nMiSmpkCldu1lVkunJm44bHLKRiRg2M/B3mL06fvyW50ezQXji9Rfb YIkYnV2d6lxaGRfBfskh6EuH0zG0J2HhsRV9oI1lYyCDw09nxD3AYTw0fop6Ms+dup+U 2DoDRIEqWmiRy1659asjKWgEFEuX9ErwBhXnQmvcMkkb/CyWadU2uZVS2/V6XNqLKBIu Wo6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733949781; x=1734554581; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yB9p36p4lL+pivp3/7EBXNjAhc1hmVNVRSf9rtYP14I=; b=cmPSUWQQ7G2B3hGyWUzh6e1JU0h6Ck0eraTCtFKIHTLm8VsqypXmWICArSL63MMlHH L0TaxfAv2BynZYp51mSBynrsIM9JTKscwC13q0oQpgcayUEaFN2f+yKQSJZxFHUG87Xs Bwicdf4QNMGcr3mUxFh3QEg/2JehfLjVxC4/5bMhwkUyjrrrvvsjK6jTIMWXk/fJKN5Z PzIe6kl3RtfOw4zTgabJBtLIc/0xqBTEa5puNCjHSaI2JFePSevE4EJq68cW3LW2/Q9a OhchlYLoS3LgBf7k87ZwMKRpzG5+eqaT4v5bi8JuiUlwhqW2tr60IqrE4opTQHcqqtm/ fmBw== X-Gm-Message-State: AOJu0YwPQIxrpbhwgdlsS+77fmIeFupYe8mi0DW7ud6AfEUirV/u+wEQ /TZ8KAxIpDy8njAftbGejAMaIqExTyms+t6GHissU8N++A2YBFYBI69lAw== X-Gm-Gg: ASbGncsUr4gn04+NiSqO0DfADuQpLtpOJLl2aAIiY8lpY7MSmbFEUYiYv+/OjU5SoFD AtdMvBuT2HzPoNvAoRKT6osKdrUyfSTaU3g9NOhuE07Ga+5pflxzUc48T85RfiNpD/TuABP9Kj7 Hkq20yvmFxY+jsuUn6IbwZPtKnvtWowjB0M7kMYUL350r7obllw3vNZCcwWBrzcfHqyzEmpvx9M UM/rdX9rum+YTeVlKjA74w4Go4UCRBGfniWG8E6GkjQcYw5dMfD7f7EIQ5ywzC6X5ZDx1UQ0n0e wM8Btwqg5Vfjuo46mcRv462f7tlQzdxdIDwewzB7obsu X-Google-Smtp-Source: AGHT+IGze6izyTeXKYEip/kg2MhRT4PfvsK/ahz4RWaLc5M+hIWUngxxt3511cZ8/U0/NyGcV4TOqA== X-Received: by 2002:a05:6e02:160b:b0:3a7:e0c0:5f0d with SMTP id e9e14a558f8ab-3ac478777a2mr11109415ab.3.1733949781436; Wed, 11 Dec 2024 12:43:01 -0800 (PST) Received: from nathan (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id e9e14a558f8ab-3a814886a1fsm33516115ab.58.2024.12.11.12.43.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Dec 2024 12:43:00 -0800 (PST) Date: Wed, 11 Dec 2024 14:42:58 -0600 From: Nathan Bossart To: pgsql-hackers@postgresql.org Cc: thomas.munro@gmail.com Subject: connection establishment versus parallel workers Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mxRcgOIb+zmJHOAe" Content-Disposition: inline List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --mxRcgOIb+zmJHOAe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --mxRcgOIb+zmJHOAe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="repro.txt" setup: psql -h "$host" -U "$user" postgres <