Message-ID: <ead38e129d5b2e1f634e90c6632dc54e61165b39.camel@cybertec.at>
Subject: Re: Heavy load on DB Cluster
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: KK CHN <kkchn.in@gmail.com>, pgsql-general <pgsql-general@postgresql.org>
Date: Thu, 05 Mar 2026 09:18:15 +0100
In-Reply-To: <CAKgGyB-R5719p1viw0ZhhFD4i7SfOamFE8Vb3-2YsAARpj6SXw@mail.gmail.com>
References: 
	<CAKgGyB-R5719p1viw0ZhhFD4i7SfOamFE8Vb3-2YsAARpj6SXw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/ead38e129d5b2e1f634e90c6632dc54e61165b39.camel%40cybertec.at>
Precedence: bulk

On Thu, 2026-03-05 at 12:30 +0530, KK CHN wrote:
> I am experiencing heavy load on my database cluster and DB server perform=
ance degrading over the time.
> vCPUs 16 ,=C2=A0 Mem 32 G=C2=A0 =C2=A0Swap : 8G=C2=A0 =C2=A0storage 5T=C2=
=A0 =C2=A0 =C2=A0 =C2=A0RHEL 9.4=C2=A0 postgres 16
>=20
>=20
> top - 11:55:18 up 175 days, =C2=A07:52, =C2=A03 users, =C2=A0load average=
: 11.07, 10.05, 9.56
> Tasks: 731 total, =C2=A014 running, 717 sleeping, =C2=A0 0 stopped, =C2=
=A0 0 zombie
> %Cpu(s): 28.8 us, =C2=A09.3 sy, =C2=A00.0 ni, 44.9 id, 13.7 wa, =C2=A00.8=
 hi, =C2=A02.5 si, =C2=A00.0 st
> MiB Mem : =C2=A031837.6 total, =C2=A0 =C2=A0531.8 free, =C2=A014773.3 use=
d, =C2=A025392.0 buff/cache
> MiB Swap: =C2=A0 8060.0 total, =C2=A0 5140.4 free, =C2=A0 2919.6 used. =
=C2=A017064.2 avail Mem
>=20
> =C2=A0 =C2=A0 PID USER =C2=A0 =C2=A0 =C2=A0PR =C2=A0NI =C2=A0 =C2=A0VIRT =
=C2=A0 =C2=A0RES =C2=A0 =C2=A0SHR S =C2=A0%CPU =C2=A0%MEM =C2=A0 =C2=A0 TIM=
E+ COMMAND
> 3148533 postgre+ =C2=A020 =C2=A0 0 8973544 =C2=A0 7.3g =C2=A0 7.3g S =C2=
=A032.9 =C2=A023.5 =C2=A0 0:22.52 postgres
> 3150012 postgre+ =C2=A020 =C2=A0 0 8991380 =C2=A0 7.4g =C2=A0 7.4g S =C2=
=A032.9 =C2=A023.9 =C2=A0 0:26.16 postgres
> 3081907 postgre+ =C2=A020 =C2=A0 0 9078400 =C2=A0 8.0g =C2=A0 7.9g R =C2=
=A021.9 =C2=A025.8 =C2=A0 2:44.53 postgres
> 3125409 postgre+ =C2=A020 =C2=A0 0 9075568 =C2=A0 8.1g =C2=A0 8.0g S =C2=
=A021.3 =C2=A026.0 =C2=A0 2:34.63 postgres
> 3126500 postgre+ =C2=A020 =C2=A0 0 9073928 =C2=A0 8.0g =C2=A0 7.9g S =C2=
=A018.3 =C2=A025.7 =C2=A0 2:33.10 postgres
> 3081925 postgre+ =C2=A020 =C2=A0 0 9059088 =C2=A0 8.2g =C2=A0 8.2g S =C2=
=A017.6 =C2=A026.5 =C2=A0 6:38.79 postgres=C2=A0
>=20
> I have pgbackrest(2.52.1) running for incremental backups to a remote rep=
oserver
> and local=C2=A0 =C2=A0WAL replication configured to an onprem standalone=
=C2=A0 instance on
> another VM in the same local LAN.=C2=A0
>=20
> archive_mode =3D on =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # en=
ables archiving; off, on, or always
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # (change requires restart)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # (empty string indicates archive_co=
mmand should
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # be used)
> archive_command =3D 'pgbackrest --stanza=3DMy_Repo archive-push %p'
>=20
> To identify the resource consuming queries I ran=C2=A0 and found=C2=A0 on=
ly one
> [40 days 17:22:59.029204 | START_REPLICATION 8E ]=C2=A0 and rest all seem=
s normal .=C2=A0 =C2=A0
>=20
> How come this START_REPLICATION running for 40 days and 17:30 Hrs Is this=
 normal ??
> Is this due to pgbackrest=C2=A0 =C2=A0 or=C2=A0 =C2=A0WAL replication to =
local VM ?

That is an active replication - or pg_receivewal, which amounts to the same=
.
That's not really a query; the standby is streaming WAL from the primary an=
d
has been doing that for over 40 days.  Nothing to worry about.

> What may be the issue and how to resolve it ?

For that, configure pg_stat_statements and use it to find your most time-co=
nsuming
statements.

Yours,
Laurenz Albe