Constant CONSOLE_MEMORY_SHARES_SQL 

const CONSOLE_MEMORY_SHARES_SQL: &str = "\
    MAX(m.memory_bytes::float8) / NULLIF(s.memory_bytes, 0) AS ram_percent,
    MAX(m.swap_bytes::float8) / NULLIF(s.memory_bytes, 0) AS swap_of_ram_percent,
    MAX(m.heap_limit::float8) / NULLIF(s.memory_bytes, 0) AS heap_limit_percent";

Worst-process shares of one process’s RAM allocation, shared by the console utilization view bodies. All three divide by the same denominator so they stack on one axis: ram_percent is the bar, swap_of_ram_percent sits on top, and heap_limit_percent marks where RAM plus swap runs out, above 1.0. Assumes the metrics relation is bound as m and the sizes relation as s.

NOTE: worst-process shares, not replica totals. memory_percent alongside them sums across processes instead; the two agree at scale=1, but above it these report “the worst process is at 98% of its own allocation” where memory_percent reports “the replica is at 32% overall”. A replica dies on one process being OOM-killed, so the chart’s limit line wants the former.

NOTE: peak RAM and peak swap are independent maxima, so under multi-process skew they can describe different processes and the stack is an upper bound.

NOTE: a size that cannot swap reads 0 here, not null. clusterd reports VmSwap whenever it can read /proc/self/status, and that is 0 for a process with no swap. Null means no sample at all: the process orchestrator, a failed usage fetch, or history predating the column. heap_limit_percent is what separates “cannot swap” from “did not swap”, reading 1.0 exactly when the cgroup grants no swap beyond RAM.

NOTE: these recombine to heap_percent where the maxima agree, so prefer that column over a fourth spelling of the same quantity.