Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lcBeT-0003Mm-0a for pgsql-admin@arkaria.postgresql.org; Thu, 29 Apr 2021 18:44:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lcBeR-0001NS-Va for pgsql-admin@arkaria.postgresql.org; Thu, 29 Apr 2021 18:44:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lcBeR-0001NL-JR for pgsql-admin@lists.postgresql.org; Thu, 29 Apr 2021 18:44:39 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lcBeP-0001uY-0L for pgsql-admin@postgresql.org; Thu, 29 Apr 2021 18:44:39 +0000 Received: by mail-wm1-x330.google.com with SMTP id k4-20020a7bc4040000b02901331d89fb83so307373wmi.5 for ; Thu, 29 Apr 2021 11:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=WSPG/xQ1m5j81Fest1Fo2CKf2TYpBzxtirJLIfAb7XA=; b=TTkX0bG+L9XaG+T1b2QDJLq2NqZ9Sh3D12YnYkjHsMOU7SepTtPjOrD7SdpcV+s4xD 7Uvw0nF+2ymcX3S6H+YQaF/ifiQ0S576NssQNiL1v9ydyn6S0GfTE+YeLK9GKTL37UVM rzWcQj+rWUP4E7qTTBe5qHYGfhSacDeA0eLLlFMTRciygb2/r5tfoZW0aAHPpocjkJdW JqH0F8mNJz8kIPFepXHfUtZ+JYB8zIlklHTGGLkMNYNaEv55qye+4G5t0ouzxG5fHb1j YeF8W2kX/k0NjcorPRLCtr9e3I6inW9cfEyaaRCBL/Yp/MTxmDdKSbmEoE4foq3Xbau1 Ttqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=WSPG/xQ1m5j81Fest1Fo2CKf2TYpBzxtirJLIfAb7XA=; b=jyZyfrnb5pA5a8zeCnAx0hKjo217caSp4lWmapHCf7viY9nysEQ498XRLWQrj/VvKT He49SGeBrr0eW4wFXBdv6ZQTYIyGDxfwrUBpcREEqjxrhmmpl6H6/IpR3TZ8uWNimyV6 8R18HLcpDg9eC95M2l/wbI2/WTvd9pA0K8vgwg2RBklOgGsFkeuBdhShMHkytzNq++m+ Gg0zA+8mOxUNEueEUWUGSROnIsoKxzM7lvtwfvcXO1/NRbKSte0eq61OmknITLRa1w/K if0ZgRywd3GTEiqp49B5ztFz7F9q6ABks9SJWMSvxgYNmJQMUKSilAsykRYp41LN/yCX s8NA== X-Gm-Message-State: AOAM531MXQbNVRnOaI+fvonmKsdhIjb0DCFl1Neq1HBcxe3fScHXmJE1 vnwUduv3XoSxXNUhBcOOZubPC1TIbx89cw== X-Google-Smtp-Source: ABdhPJwe79Yhd9m+zxWztnT2qCPP+5yBbu5PAaNWFr9TbyQ+5Wfyr/9PjkzS7d5EPHCvC3EdHeoRvA== X-Received: by 2002:a05:600c:210f:: with SMTP id u15mr12474726wml.115.1619721875948; Thu, 29 Apr 2021 11:44:35 -0700 (PDT) Received: from localhost.localdomain (91-115-149-68.adsl.highway.telekom.at. [91.115.149.68]) by smtp.gmail.com with ESMTPSA id t12sm5887106wrs.42.2021.04.29.11.44.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Apr 2021 11:44:35 -0700 (PDT) Message-ID: <38d3ba77341d35afbee921cf8dbce4fe70951763.camel@cybertec.at> Subject: Re: WALWriteLocks From: Laurenz Albe To: Don Seiler Cc: pgsql-admin Date: Thu, 29 Apr 2021 20:44:35 +0200 In-Reply-To: References: <63f24de419af530402a16a97c5e5ec977f4092dc.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2021-04-29 at 11:11 -0500, Don Seiler wrote: > On Thu, Apr 29, 2021 at 1:38 AM Laurenz Albe wrote: > > My gues is that you have too many active client connections, and you are suffering > > from contention between the many backends that all want to write WAL. > > > > In that case, use a connection pool to limit the number of active connections. > > We do have pgbouncer in place already. What is the maximum pool size? How many connections in state "active" do you have? > What I really want to know in this case is if there is some other PG operation that > accounts for a WALWriteLock wait, or is it always an I/O (write) to the WAL file > storage, and we can focus our investigation there? WALWriteLock: must be held to write WAL buffers to disk (XLogWrite or XLogFlush). It might be I/O overload, but it could also be internal contention for the lock. Check the "%iowait" column in "sar -u 1". Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com