Description
client/src/components/Dashboard/ServerDashboard/PostgresOverviewSection.tsx:336
plots numbackends and sessions as two series on a single shared
axis. These are different kinds of quantity:
-
numbackends is a gauge — backends connected right now, bounded by
max_connections, typically in the tens or low hundreds.
-
sessions is a cumulative counter — total sessions established
since stats_reset, climbing into the thousands or millions.
On a shared axis the sessions staircase sets the scale and pins
numbackends to a flat line at the bottom. The legend labels them
"Backends" and "Sessions" as though they were comparable, inviting the
reader to conclude something like "40 backends and 85,000 sessions" as
if both were concurrent.
Proposed fix
Split into two charts.
Connections shows numbackends raw, with a max_connections
reference line. A stacked breakdown from pg_stat_activity covering
active, idle and idle-in-transaction would be a significant
improvement, since idle-in-transaction is where most real incidents
live.
Connection rate shows sessions_per_sec, which is new sessions per
second. This is currently invisible and is a strong signal on its own.
The diagnostic value is in the pair: a high session rate with a low
backend count means connection churn with no pooler, while
numbackends trending toward max_connections means exhaustion risk.
Related counting caveat
The pg_stat_database probe filters WHERE datname = current_database() (collector/src/probes/pg_stat_database_probe.go:66),
so summing numbackends across monitored databases undercounts the
server total. It misses unmonitored databases, and numbackends never
counts walsenders or autovacuum workers, which still consume
connection slots.
Either label the chart as per-database, or take the server-wide count
from pg_stat_activity.
Acceptance criteria
-
Two separate charts, each with correct units.
-
max_connections reference line on the connections chart.
-
Chart labelling makes the per-database scope explicit, or the count
is sourced server-wide.
Description
client/src/components/Dashboard/ServerDashboard/PostgresOverviewSection.tsx:336plots
numbackendsandsessionsas two series on a single sharedaxis. These are different kinds of quantity:
numbackendsis a gauge — backends connected right now, bounded bymax_connections, typically in the tens or low hundreds.sessionsis a cumulative counter — total sessions establishedsince
stats_reset, climbing into the thousands or millions.On a shared axis the
sessionsstaircase sets the scale and pinsnumbackendsto a flat line at the bottom. The legend labels them"Backends" and "Sessions" as though they were comparable, inviting the
reader to conclude something like "40 backends and 85,000 sessions" as
if both were concurrent.
Proposed fix
Split into two charts.
Connections shows
numbackendsraw, with amax_connectionsreference line. A stacked breakdown from
pg_stat_activitycoveringactive, idle and idle-in-transaction would be a significant
improvement, since idle-in-transaction is where most real incidents
live.
Connection rate shows
sessions_per_sec, which is new sessions persecond. This is currently invisible and is a strong signal on its own.
The diagnostic value is in the pair: a high session rate with a low
backend count means connection churn with no pooler, while
numbackendstrending towardmax_connectionsmeans exhaustion risk.Related counting caveat
The
pg_stat_databaseprobe filtersWHERE datname = current_database()(collector/src/probes/pg_stat_database_probe.go:66),so summing
numbackendsacross monitored databases undercounts theserver total. It misses unmonitored databases, and
numbackendsnevercounts walsenders or autovacuum workers, which still consume
connection slots.
Either label the chart as per-database, or take the server-wide count
from
pg_stat_activity.Acceptance criteria
Two separate charts, each with correct units.
max_connectionsreference line on the connections chart.Chart labelling makes the per-database scope explicit, or the count
is sourced server-wide.