public inbox for [email protected]  

help / color / mirror / Atom feed

From: Raj <[email protected]>
To: Frank Heikens <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: Low TPS
Date: Fri, 5 Jun 2026 10:15:46 +0530
Message-ID: <CAJk5Atbbf86c26FqzL5+4y8cZTenNpedp-KkiQhaKEboneM0fg@mail.gmail.com> (raw)
In-Reply-To: <CAJk5AtZ8P2TqJL+_Nw-TzvY2Nc+wAufA7TRGNQEB_3DK2je_dw@mail.gmail.com>
References: <CAJk5AtbCHYXpDQ9QPoLy5S=edTHxjMC3wpyWX1ERQcdo-hvPGw@mail.gmail.com>
	<[email protected]>
	<CAJk5Atbd82L_rbCSMobEX2DmJ8v4be4KdekFHz_CLGBqek4f2Q@mail.gmail.com>
	<CAJk5AtZ8P2TqJL+_Nw-TzvY2Nc+wAufA7TRGNQEB_3DK2je_dw@mail.gmail.com>

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, <[email protected]> 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, <[email protected]> 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, <[email protected]> wrote:
>>
>>> 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)

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: <CAJk5Atbbf86c26FqzL5+4y8cZTenNpedp-KkiQhaKEboneM0fg@mail.gmail.com>

* 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