Re: WALWriteLocks

From: Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com>
To: Don Seiler <don(at)seiler(dot)us>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: WALWriteLocks
Date: 2021-04-29 17:05:01
Message-ID: CAM+6J94EyTQLOk8EQ2W8kTnS1Ez5kM9a-udao8U5FggK5_mhdw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

I guess details on io waits/ iops saturation etc metrics would need to be
ruled out for further discussion.

Do the dashboards wrt above metrics look ok?

We had vms with unlimited iops and no synchronous replication, so I do not
recall this piling up of locks issues atleast till 1tb dbs on ssds till
pg11.
Googling does mention some things wrt tuning of wal buffers etc, but I
believe ruling out resource exhaustion is important.

On Thu, 29 Apr 2021 at 9:42 PM Don Seiler <don(at)seiler(dot)us> 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.
>
> Thanks for the replies so far.
>
> 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?
>
> Don.
>
> --
> Don Seiler
> www.seiler.us
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Vijaykumar Jain 2021-04-29 18:43:48 Re: WALWriteLocks
Previous Message Don Seiler 2021-04-29 16:11:44 Re: WALWriteLocks