From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Don Seiler <don@seiler.us>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: WALWriteLocks
Date: Thu, 29 Apr 2021 20:44:35 +0200
Message-ID: <38d3ba77341d35afbee921cf8dbce4fe70951763.camel@cybertec.at> (raw)
In-Reply-To: <CAHJZqBDHZyPCXjnOhS2C9YoBTaJ0_e47M_q7pob+F0VT_B48fQ@mail.gmail.com>
References: <CAHJZqBDXNEOZDYQXB+xUK2ie-Tjzmn72RHVec-NsCNyU4TeydQ@mail.gmail.com>
<63f24de419af530402a16a97c5e5ec977f4092dc.camel@cybertec.at>
<CAHJZqBDHZyPCXjnOhS2C9YoBTaJ0_e47M_q7pob+F0VT_B48fQ@mail.gmail.com>
On Thu, 2021-04-29 at 11:11 -0500, Don Seiler wrote:
> On Thu, Apr 29, 2021 at 1:38 AM Laurenz Albe <laurenz.albe@cybertec.at> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: laurenz.albe@cybertec.at, don@seiler.us
Subject: Re: WALWriteLocks
In-Reply-To: <38d3ba77341d35afbee921cf8dbce4fe70951763.camel@cybertec.at>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox