Skip to main content

Activity & Throughput Trends

The Activity & Throughput tab visualizes how your PostgreSQL instance's workload intensity has evolved over the selected period. It tracks transaction rates, read/write volumes, and connection patterns over time.

{screenshot: trends-activity-throughput-tab}


Metrics Displayed

Transactions

A line chart showing the evolution of transaction throughput:

MetricDescription
Commits/secRate of committed transactions per second
Rollbacks/secRate of rolled-back transactions per second
Rollback ratioRollbacks as a percentage of total transactions

{screenshot: trends-transactions-chart}

A rising rollback ratio over time is a warning sign — it may indicate increasing constraint violations, application errors or lock timeout issues.

Reads & Writes

MetricDescription
Blocks read/secTotal block reads (cache + disk)
Blocks hit/secBlocks served from buffer cache
Blocks written/secBlocks written to disk
Cache hit ratioBlocks hit / total reads × 100

{screenshot: trends-reads-writes-chart}

A declining cache hit ratio trend over weeks may indicate the working dataset is growing beyond shared_buffers capacity — a signal to increase memory allocation or review query plans.

Connections

MetricDescription
Active connectionsAverage active connections per snapshot
Idle connectionsAverage idle connections per snapshot
Idle in transactionAverage idle-in-transaction sessions
Peak connectionsMaximum connections observed in the period

{screenshot: trends-connections-chart}

A steady growth in idle connections over time may indicate connection pool misconfiguration or application connection leaks.


Organic Growth

A gradual, proportional increase in all metrics (commits, reads, writes) reflects natural workload growth — useful for capacity planning projections.

Disproportionate Write Growth

If writes are growing significantly faster than reads or commits, investigate whether a batch process, logging table or audit trail is generating unexpected data volume.

Declining Cache Hit Ratio

Investigate which databases or queries are most responsible for physical reads (visible in AWR Top SQL by I/O). Consider increasing shared_buffers or adding indexes to reduce sequential scans.


Next Steps