Memory Leak Estimator
Estimate time until out-of-memory based on observed process memory leak rate.
Inputs
Leak Rate (MB/hour)
30.000
Status
Moderate growth — estimated 11.1 days until available memory is exhausted.
Estimated Hours Until OOM
266.7
Estimated Days Until OOM
11.11
Step by step
Values used
Memory Usage at Start (MB) = 500; Memory Usage Now (MB) = 620; Hours Elapsed Between Measurements = 4; Memory Available Before OOM (MB) = 8,000
Leak rate and time to OOM
leak_rate = (mem_now − mem_start) / hours_elapsed; time_to_OOM = available_memory / leak_rate
Leak Rate (MB/hour)
= 30.000
Status
= Moderate growth — estimated 11.1 days until available memory is exhausted.
Estimated Hours Until OOM
= 266.70
Estimated Days Until OOM
= 11.11
How it works
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.
Formula
Leak rate and time to OOM
leak_rate = (mem_now − mem_start) / hours_elapsed; time_to_OOM = available_memory / leak_rate
- M_now
- current memory usage
- M_start
- starting memory usage
- \Delta t
- hours elapsed
- M_avail
- memory available before OOM
Frequently Asked Questions
How do I get accurate RSS measurements for this calculator?
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.
Could rising memory usage just be caching, not a leak?
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.
What should I do if this shows a leak with only a few hours until OOM?
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.