Re: WALWriteLocks

ok one final query.

PostgreSQL: Documentation: 13: 19.5. Write Ahead Log
<https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT>
PostgreSQL: Documentation: 13: 19.6. Replication
<https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES>

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(at)seiler(dot)us> wrote:

> On Mon, May 24, 2021 at 10:38 AM Vijaykumar Jain <
> vijaykumarjain(dot)github(at)gmail(dot)com> wrote:
>
>> Thanks.
>>
>> For my ref:
>> Virtual machine and disk performance - Azure Virtual Machines | Microsoft
>> Docs
>> <https://docs.microsoft.com/en-us/azure/virtual-machines/disks-performance>
>>
>
> 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