Re: Use fadvise in wal replay

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Kirill Reshke <reshke(at)double(dot)cloud>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Use fadvise in wal replay
Date: 2022-06-21 09:35:13
Message-ID: CAA4eK1+zR_ZPeuG1K8dszsu+ajSDgsO2LvVA2szFSLBah68QQQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 21, 2022 at 1:07 PM Kirill Reshke <reshke(at)double(dot)cloud> wrote:
>
> Recently we faced a problem with one of our production clusters. We use a cascade replication setup in this cluster, that is: master, standby (r1), and cascade standby (r2). From time to time, the replication lag on r1 used to grow, while on r2 it did not. Analysys showed that r1 startup process was spending a lot of time in reading wal from disk. Increasing /sys/block/md2/queue/read_ahead_kb to 16384 (from 0) helps in this case. Maybe we can add fadvise call in postgresql startup, so it would not be necessary to change settings on the hypervisor?
>

I wonder if the newly introduced "recovery_prefetch" [1] for PG-15 can
help your case?

[1] - https://www.postgresql.org/docs/devel/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2022-06-21 09:38:27 Re: Make COPY extendable in order to support Parquet and other formats
Previous Message Amit Langote 2022-06-21 09:22:56 Re: Replica Identity check of partition table on subscriber