Estimate time until out-of-memory based on observed process memory leak rate.
Sampling a process's RSS (resident set size, from `ps` or /proc/<pid>/status) at two points in time gives a linear leak rate, which extrapolated forward estimates a rough time-to-OOM. Real leaks are rarely perfectly linear — some plateau due to internal caching limits, others accelerate as fragmentation worsens allocator behavior — so this is a triage tool to gauge urgency (hours vs. weeks), not a precise deadline; confirm suspected leaks with a proper profiler (valgrind, heaptrack, or language-specific tools) before deploying a fix.
Leak rate and time to OOM
leak_rate = (mem_now − mem_start) / hours_elapsed; time_to_OOM = available_memory / leak_rate
Sample `ps -o rss= -p <pid>` (in KB) or read VmRSS from /proc/<pid>/status at two points separated by enough time to see a clear trend — a few hours minimum for most leaks, since short intervals are dominated by noise from normal allocator behavior and garbage collection cycles.
Yes — many applications (JVMs, databases, web servers with connection pools) grow memory usage during warm-up and then plateau at a stable working-set size. A genuine leak keeps growing indefinitely without plateauing; confirm by sampling over a longer window before concluding it's a true leak.
Treat it as urgent: capture a heap/memory profile immediately (many runtimes support live heap dumps, e.g. jmap for JVM or gcore for native processes) before restarting the process, since restarting resets the leak and destroys the evidence needed to diagnose the root cause.