Re: WALWriteLocks - Mailing list pgsql-admin

From Vijaykumar Jain
Subject Re: WALWriteLocks
Date
Msg-id CAM+6J94ptndTjf1dUi7704a-O4LiBffNpMmEiY86BfxFDvHQaw@mail.gmail.com
Whole thread Raw
In response to Re: WALWriteLocks  (Don Seiler <don@seiler.us>)
Responses Re: WALWriteLocks
List pgsql-admin
ok one final query.


Do you have synchronous_standby_names enabled and have non zero nodes here?
slow network or disk on standby may result in WALWrite contention on primary, even when primary has no issue.


 



 


On Mon, 24 May 2021 at 21:21, Don Seiler <don@seiler.us> wrote:
On Mon, May 24, 2021 at 10:38 AM Vijaykumar Jain <vijaykumarjain.github@gmail.com> wrote:

We've definitely been over these docs, with and without their support team. We are well below the caps on the both the disks and the VM size in use.
 
Sorry, i just want to use all the info, i have less exp :)
do you generate large wals ? 

Our WALs are standard 16MB in size.
 
if your checkpoint_completion_target is aggressive, it will result in a lot of io.
if the checkpoint is spread over a larger time window, maybe it will reduce frequent i/o pressure.
but for that log_checkpoints needs to be turned on if they are hogging the iops.

checkpoint_timeout is 5min, max_wal_size is 5GB. The vast majority of checkpoints are time-initiated, not wal-initiated. We've tuned this in the past. Over the past 16 hours there have been only 5 checkpoints started due to wal pressure. There was no such wal-initiated checkpoint that corresponds to the most recent WALWriteLock spike either.

Don.

--
Don Seiler
www.seiler.us


--
Thanks,
Vijay
Mumbai, India

pgsql-admin by date:

Previous
From: Don Seiler
Date:
Subject: Re: WALWriteLocks
Next
From: Don Seiler
Date:
Subject: Re: WALWriteLocks