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

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

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 whethe=
r
>> 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
>> is actually limiting throughput or whether the bottleneck is elsewhere.
>>
>> Could you share the above information and some monitoring graphs from th=
e
>> 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.th=
e
>> metric we need to monitor from our side. Vcpu 32, 128GB RAM
>>
>

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

<div dir=3D"auto">Cache hir ratio is 74. When I checked there were only cou=
ple of big partition tables have less cache hit ratio=C2=A0</div><br><div c=
lass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_=
attr">On Fri, 5 Jun 2026, 09:17 Raj, &lt;<a href=3D"mailto:rajeshkumar.dba0=
9@gmail.com">rajeshkumar.dba09@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto">Postgres 17.9<div dir=3D"auto">VM</d=
iv><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" dir=3D"auto">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, 4 Jun 2026, 09:48 Frank Heike=
ns, &lt;<a href=3D"mailto:frank@elevarq.com" target=3D"_blank" rel=3D"noref=
errer">frank@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>