public inbox for [email protected]
help / color / mirror / Atom feedFrom: Raj <[email protected]>
To: Frank Heikens <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: Low TPS
Date: Fri, 5 Jun 2026 10:14:37 +0530
Message-ID: <CAJk5AtZ8P2TqJL+_Nw-TzvY2Nc+wAufA7TRGNQEB_3DK2je_dw@mail.gmail.com> (raw)
In-Reply-To: <CAJk5Atbd82L_rbCSMobEX2DmJ8v4be4KdekFHz_CLGBqek4f2Q@mail.gmail.com>
References: <CAJk5AtbCHYXpDQ9QPoLy5S=edTHxjMC3wpyWX1ERQcdo-hvPGw@mail.gmail.com>
<[email protected]>
<CAJk5Atbd82L_rbCSMobEX2DmJ8v4be4KdekFHz_CLGBqek4f2Q@mail.gmail.com>
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) 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: <CAJk5AtZ8P2TqJL+_Nw-TzvY2Nc+wAufA7TRGNQEB_3DK2je_dw@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