public inbox for [email protected]  

help / color / mirror / Atom feed

From: Frank Heikens <[email protected]>
To: Raj <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: Low TPS
Date: Thu, 4 Jun 2026 04:18:12 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJk5AtbCHYXpDQ9QPoLy5S=edTHxjMC3wpyWX1ERQcdo-hvPGw@mail.gmail.com>
References: <CAJk5AtbCHYXpDQ9QPoLy5S=edTHxjMC3wpyWX1ERQcdo-hvPGw@mail.gmail.com>

Hi,

At the moment there isn’t 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 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 PM, Raj <[email protected]> wrote:
> 
> 
> Hi all,
> 
> If the application teams they are able achive only 60TPS and this is not expected. They are calculating based on total suçcess 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

view thread (5+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Low TPS
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox