MIME-Version: 1.0
References: 
 <CAJk5AtbCHYXpDQ9QPoLy5S=edTHxjMC3wpyWX1ERQcdo-hvPGw@mail.gmail.com>
 <1F4B10F9-E3E1-4FC9-AD8F-95B20CC48106@elevarq.com>
 <CAJk5Atbd82L_rbCSMobEX2DmJ8v4be4KdekFHz_CLGBqek4f2Q@mail.gmail.com>
 <CAJk5AtZ8P2TqJL+_Nw-TzvY2Nc+wAufA7TRGNQEB_3DK2je_dw@mail.gmail.com>
In-Reply-To: 
 <CAJk5AtZ8P2TqJL+_Nw-TzvY2Nc+wAufA7TRGNQEB_3DK2je_dw@mail.gmail.com>
From: Raj <rajeshkumar.dba09@gmail.com>
Date: Fri, 5 Jun 2026 10:15:46 +0530
Message-ID: 
 <CAJk5Atbbf86c26FqzL5+4y8cZTenNpedp-KkiQhaKEboneM0fg@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="0000000000004524ba06537a56e2"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJk5Atbbf86c26FqzL5%2B4y8cZTenNpedp-KkiQhaKEboneM0fg%40mail.gmail.com>
Precedence: bulk

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

We font have any graphs...we have to monitor manually... I am using the OS
watch command to.monitor multiple metrics in multiple screens

On Fri, 5 Jun 2026, 10:14 Raj, <rajeshkumar.dba09@gmail.com> wrote:

> Cache hir ratio is 74. When I checked there were only couple of big
> partition tables have less cache hit ratio
>
> On Fri, 5 Jun 2026, 09:17 Raj, <rajeshkumar.dba09@gmail.com> wrote:
>
>> 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 wheth=
er
>>> 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, storag=
e
>>> 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
>>> is 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>=
 wrote:
>>> >
>>> > =EF=BB=BF
>>> > Hi all,
>>> >
>>> > If the application teams they are able achive only 60TPS and this is
>>> not expected. They are calculating based on total su=C3=A7cess requests=
/minutes
>>> 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
>>>
>>

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

<div dir=3D"auto">We font have any graphs...we have to monitor manually... =
I am using the OS watch command to.monitor multiple metrics in multiple scr=
eens</div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"=
ltr" class=3D"gmail_attr">On Fri, 5 Jun 2026, 10:14 Raj, &lt;<a href=3D"mai=
lto:rajeshkumar.dba09@gmail.com">rajeshkumar.dba09@gmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">Cache hir ratio =
is 74. When I checked there were only couple of big partition tables have l=
ess cache hit ratio=C2=A0</div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Fri, 5 Jun 2026, 09:17 Raj, &lt;<a href=3D"mail=
to:rajeshkumar.dba09@gmail.com" target=3D"_blank" rel=3D"noreferrer">rajesh=
kumar.dba09@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><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"><b=
r></div><div dir=3D"auto">Disk utlization means - IO or pgdats is increasin=
g?</div><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Thu, 4 Jun 2026, 09:48 Frank Heikens, &lt;<a href=3D"=
mailto:frank@elevarq.com" rel=3D"noreferrer noreferrer" target=3D"_blank">f=
rank@elevarq.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-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>