Message-ID: <1e134f4d86881e35dad2147654d49735044eb40a.camel@cybertec.at>
Subject: Re: WAL replay is too slow on secondary server
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: OMPRAKASH SAHU <sahuop2121@gmail.com>, pgsql-admin@lists.postgresql.org
Date: Thu, 30 Oct 2025 11:03:40 +0100
In-Reply-To: 
 <CAOZWJqPc+s_vA-UfWWLR0s6Mt+DCffjXXVyLHJNJiuMrDLTYcA@mail.gmail.com>
References: 
	<CAOZWJqPc+s_vA-UfWWLR0s6Mt+DCffjXXVyLHJNJiuMrDLTYcA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/1e134f4d86881e35dad2147654d49735044eb40a.camel%40cybertec.at>
Precedence: bulk

On Thu, 2025-10-30 at 10:06 +0530, OMPRAKASH SAHU wrote:
> We have a postgresql cluster setup using patroni.
> The DB is being used for heavy transactional application, now the problem=
=C2=A0is 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.
>=20
> but the WAL is being accumulated on the replica as usual and applying wal=
 is having no improvement.
> changed=C2=A0the maintenance_io_concurrency on replica to 32.
> CPU utilization max=3D20% , RAM utilization is also max 20.

Is the disk saturated?

> I would request your thoughts and suggestions if we can get rid of this s=
lowness and get some speed.

WAL replay during streaming replication is single-threaded.
So you can only use a faster CPU or disk, depending on what is the bottlene=
ck.
Perhaps your shared buffers are too small, and you have cache contention.

Yours,
Laurenz Albe