TL;DR: The dashboard "Memory" graph and the cgroup counters inside the container tell two different stories, and we can't determine from the docs which one drives usage billing. We need the exact definition of the billed memory metric to make an infrastructure decision.

What we observe

The dashboard metric cannot be cgroup memory.current. On 2026-07-29, after lowering shared_buffers to 1.5 GB, the dashboard showed a trough of 1.10 GB — below shared_buffers itself. Inside the container, /sys/fs/cgroup/memory.stat showed shmem = 1.669 GB (shared buffers are anonymous shared memory, not reclaimable without swap), so memory.current can never drop that low. At another point in the same window, memory.current read 6.26 GB while the dashboard showed ~2.8 GB. So the dashboard appears to subtract at least inactive_file — but we found no documentation of the formula.

A daily one-shot read parks gigabytes in inactive page cache for hours. The template's pgBackRest job reads the whole database daily (e.g. 2026-07-27 10:56–10:58 UTC: diff backup size = 4.9GB in 74 s). memory.stat measured ~3 h later: inactive_file = 3.42 GB vs active_file = 0.37 GB, anon = 92 MB. With memory.max = 32 GB there is no memory pressure, so the kernel never reclaims these pages. On the dashboard this shows up as a vertical +4 GB step followed by a 6–7 GB plateau lasting ~12+ hours (e.g. 2026-07-30 ~13:00 UTC until 2026-07-31 ~06:00 UTC).

Questions

What is the exact formula of the dashboard "Memory" metric for a service (in cgroup v2 terms — e.g. memory.current − inactive_file, working set, etc.)?

Which metric is used for usage billing ($/GB-min)? Is it the same as the dashboard metric, or raw memory.current?

Concretely: during the plateaus described above, are we billed for the inactive page cache left behind by the backup (pages read once, never touched again), and if the dashboard subtracts inactive pages, on what aging/decay schedule?

Is there a supported way to have that cache reclaimed without setting a hard replica memory limit? (The docs state a service that exceeds its limit crashes — an OOM kill of a production Postgres is not acceptable for us, so a hard cap is not an option.) E.g. a memory.high-style soft limit, or writing to memory.reclaim — is cgroupfs writable from inside the container, and is that supported?

Why we ask: our DB memory bill has doubled since May while the actual hot working set (measured via active_file + shmem) is ~2 GB. Before doing any further engineering (data retention, backup changes) we need to know whether the OS page cache from backups/batch jobs is part of the billed quantity. Happy to share full memory.stat dumps and timestamps if useful.