Unexplained memory growth on Heroku dyno during sustained load

Goal: determine whether a steady rise in RSS reported by Heroku’s dyno metrics reflects a genuine memory leak in the application or expected platform behavior such as garbage‑collection jitter or undocumented swap usage.

Constraints: Heroku exposes only the total memory footprint via ps:info, with no per‑process or heap breakdown; dynos may restart after deploys or resource rebalancing, masking gradual trends; the log drain’s 10 000‑line/minute limit can drop diagnostic output, and the exact swap allocation granularity per container is not documented, making attribution difficult without external add‑ons.

Questions: What magnitude of memory increase over multiple dyno cycles qualifies as a leak versus normal variance? How can one isolate application‑specific memory from platform overhead using only Heroku‑provided metrics? Is there a way to observe memory behavior reliably without triggering dyno restarts that would reset the measurement?