| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Don Seiler <don(at)seiler(dot)us> |
| Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: WALWriteLocks |
| Date: | 2021-04-29 18:44:35 |
| Message-ID: | 38d3ba77341d35afbee921cf8dbce4fe70951763.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Thu, 2021-04-29 at 11:11 -0500, Don Seiler wrote:
> On Thu, Apr 29, 2021 at 1:38 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2021-04-29 18:52:03 | Re: WALWriteLocks |
| Previous Message | Vijaykumar Jain | 2021-04-29 18:43:48 | Re: WALWriteLocks |