Re: Low TPS

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, <rajeshkumar(dot)dba09(at)gmail(dot)com> 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, <rajeshkumar(dot)dba09(at)gmail(dot)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(at)elevarq(dot)com> 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 <rajeshkumar(dot)dba09(at)gmail(dot)com> 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
>>>
>>