public inbox for [email protected]
help / color / mirror / Atom feedLow TPS
5+ messages / 2 participants
[nested] [flat]
* Low TPS
@ 2026-06-04 04:11 Raj <[email protected]>
2026-06-04 04:18 ` Re: Low TPS Frank Heikens <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Raj @ 2026-06-04 04:11 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
--000000000000d703b8065365bdd3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Low TPS
2026-06-04 04:11 Low TPS Raj <[email protected]>
@ 2026-06-04 04:18 ` Frank Heikens <[email protected]>
2026-06-05 03:47 ` Re: Low TPS Raj <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Frank Heikens @ 2026-06-04 04:18 UTC (permalink / raw)
To: Raj <[email protected]>; +Cc: Pgsql-admin <[email protected]>
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Low TPS
2026-06-04 04:11 Low TPS Raj <[email protected]>
2026-06-04 04:18 ` Re: Low TPS Frank Heikens <[email protected]>
@ 2026-06-05 03:47 ` Raj <[email protected]>
2026-06-05 04:44 ` Re: Low TPS Raj <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Raj @ 2026-06-05 03:47 UTC (permalink / raw)
To: Frank Heikens <[email protected]>; +Cc: Pgsql-admin <[email protected]>
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
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Low TPS
2026-06-04 04:11 Low TPS Raj <[email protected]>
2026-06-04 04:18 ` Re: Low TPS Frank Heikens <[email protected]>
2026-06-05 03:47 ` Re: Low TPS Raj <[email protected]>
@ 2026-06-05 04:44 ` Raj <[email protected]>
2026-06-05 04:45 ` Re: Low TPS Raj <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Raj @ 2026-06-05 04:44 UTC (permalink / raw)
To: Frank Heikens <[email protected]>; +Cc: Pgsql-admin <[email protected]>
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
>>
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Low TPS
2026-06-04 04:11 Low TPS Raj <[email protected]>
2026-06-04 04:18 ` Re: Low TPS Frank Heikens <[email protected]>
2026-06-05 03:47 ` Re: Low TPS Raj <[email protected]>
2026-06-05 04:44 ` Re: Low TPS Raj <[email protected]>
@ 2026-06-05 04:45 ` Raj <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Raj @ 2026-06-05 04:45 UTC (permalink / raw)
To: Frank Heikens <[email protected]>; +Cc: Pgsql-admin <[email protected]>
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
>>>
>>
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-06-05 04:45 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-04 04:11 Low TPS Raj <[email protected]>
2026-06-04 04:18 ` Frank Heikens <[email protected]>
2026-06-05 03:47 ` Raj <[email protected]>
2026-06-05 04:44 ` Raj <[email protected]>
2026-06-05 04:45 ` Raj <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox