MIME-Version: 1.0
References: 
 <CAJk5AtbCHYXpDQ9QPoLy5S=edTHxjMC3wpyWX1ERQcdo-hvPGw@mail.gmail.com>
 <1F4B10F9-E3E1-4FC9-AD8F-95B20CC48106@elevarq.com>
In-Reply-To: <1F4B10F9-E3E1-4FC9-AD8F-95B20CC48106@elevarq.com>
From: Raj <rajeshkumar.dba09@gmail.com>
Date: Fri, 5 Jun 2026 09:17:53 +0530
Message-ID: 
 <CAJk5Atbd82L_rbCSMobEX2DmJ8v4be4KdekFHz_CLGBqek4f2Q@mail.gmail.com>
Subject: Re: Low TPS
To: Frank Heikens <frank@elevarq.com>
Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000005d39140653798702"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJk5Atbd82L_rbCSMobEX2DmJ8v4be4KdekFHz_CLGBqek4f2Q%40mail.gmail.com>
Precedence: bulk

--0000000000005d39140653798702
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Postgres 17.9
VM
Pgnouncer
Mixed workload

Disk utlization means - IO or pgdats is increasing?


On Thu, 4 Jun 2026, 09:48 Frank Heikens, <frank@elevarq.com> wrote:

> Hi,
>
> At the moment there isn=E2=80=99t enough information to determine whether
> PostgreSQL is the bottleneck.
>
> A throughput of 60 TPS by itself does not tell us much. The limitation
> could be in the application, connection pool, network, database, storage
> subsystem, external services, or even the load test setup itself.
>
> Could you provide some additional information?
>
> * PostgreSQL version
> * Deployment type (bare metal, VM, AWS RDS, Azure, etc.)
> * Number of application instances
> * Connection pool being used (PgBouncer, HikariCP, etc.)
> * Average response time during the test
> * Number of active database connections
> * CPU, memory, and disk utilization during the test
> * Top queries from pg_stat_statements
> * Wait events observed during the test
> * Whether the workload is read-heavy, write-heavy, or mixed
>
> From the database side, I would monitor at least:
>
> * CPU utilization
> * Memory utilization
> * I/O throughput and latency
> * Active sessions (pg_stat_activity)
> * Wait events
> * Transactions per second
> * Cache hit ratio
> * Checkpoint activity
> * WAL generation rate
> * Query execution times (pg_stat_statements)
> * Lock contention
> * Replication lag (if applicable)
>
> Without these metrics, it is impossible to determine whether PostgreSQL i=
s
> actually limiting throughput or whether the bottleneck is elsewhere.
>
> Could you share the above information and some monitoring graphs from the
> load test?
>
> Frank
>
>
>
> > On Jun 3, 2026, at 9:11=E2=80=AFPM, Raj <rajeshkumar.dba09@gmail.com> w=
rote:
> >
> > =EF=BB=BF
> > Hi all,
> >
> > If the application teams they are able achive only 60TPS and this is no=
t
> expected. They are calculating based on total su=C3=A7cess requests/minut=
es we
> ran load test*60.
> >
> > From Database side what we can do and during.load test what are all.the
> metric we need to monitor from our side. Vcpu 32, 128GB RAM
>

--0000000000005d39140653798702
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Postgres 17.9<div dir=3D"auto">VM</div><div dir=3D"auto">=
Pgnouncer</div><div dir=3D"auto">Mixed workload</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Disk utlization means - IO or pgdats is increasing?=
</div><br><br><div class=3D"gmail_quote gmail_quote_container" dir=3D"auto"=
><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 4 Jun 2026, 09:48 Frank Heik=
ens, &lt;<a href=3D"mailto:frank@elevarq.com">frank@elevarq.com</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
At the moment there isn=E2=80=99t enough information to determine whether P=
ostgreSQL is the bottleneck.<br>
<br>
A throughput of 60 TPS by itself does not tell us much. The limitation coul=
d be in the application, connection pool, network, database, storage subsys=
tem, external services, or even the load test setup itself.<br>
<br>
Could you provide some additional information?<br>
<br>
* PostgreSQL version<br>
* Deployment type (bare metal, VM, AWS RDS, Azure, etc.)<br>
* Number of application instances<br>
* Connection pool being used (PgBouncer, HikariCP, etc.)<br>
* Average response time during the test<br>
* Number of active database connections<br>
* CPU, memory, and disk utilization during the test<br>
* Top queries from pg_stat_statements<br>
* Wait events observed during the test<br>
* Whether the workload is read-heavy, write-heavy, or mixed<br>
<br>