Re: WAL replay is too slow on secondary server

Hi OM,
Hi Laurenz,

Thank you for your insights.

I apologize for my previous suggestion regarding network speed; upon
further review, it was not the correct cause in this scenario.

Based on the current observations and system metrics, the accumulation of
WAL on the standby server points to disk I/O limitations during replay—not
network speed. CPU and RAM usage remain low, and WAL traffic is reaching
the replica without delay, but replay/apply on disk is slow.

The root cause appears to be disk subsystem performance and the
single-threaded nature of WAL replay in PostgreSQL recovery. Optimizing
disk throughput or reconfiguring memory may help, but network latency does
not seem to be affecting this scenario.

Regards,
Shubhang

On Thu, 30 Oct 2025 at 17:45, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:

> On Thu, 2025-10-30 at 17:08 +0530, Shubhang Joshi wrote:
> > On Thu, 30 Oct, 2025, 10:07 am OMPRAKASH SAHU, <sahuop2121(at)gmail(dot)com>
> wrote:
> > > We have a postgresql cluster setup using patroni.
> > > The DB is being used for heavy transactional application, now the
> problem is that on replica server WAL replay is too slow.
> > > We have increased the IOPS to 6k and Throughput to 600 on nvme EBS
> volume of wal directory and 10k &800 on data directory.
> > >
> > > but the WAL is being accumulated on the replica as usual and applying
> wal is having no improvement.
> >
> > Please check the network speed — we faced a similar issue earlier, and
> it turned out to be related to network performance.
> > Kindly verify the network latency with your network team as well.
>
> If WAL is piling up on the standby, how can network speed be the problem?
>
> Yours,
> Laurenz Albe
>