Memory Leak Estimator
Estimate time until out-of-memory based on observed process memory leak rate.
About Memory Leak Estimator
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
Worked example
With the default values below, Memory Leak Estimator returns Leak Rate (MB/hour) of 30.000. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Memory Usage at Start (MB)minimum 0
- 500
- Memory Usage Now (MB)minimum 0
- 620
- Hours Elapsed Between Measurementsminimum 0.01
- 4
- Memory Available Before OOM (MB)minimum 0
- 8,000
Results
- 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
- 1Values used
- 2Leak rate and time to OOM
- 3Leak Rate (MB/hour)= 30.000
- 4Status= Moderate growth — estimated 11.1 days until available memory is exhausted.
- 5Estimated Hours Until OOM= 266.70
- 6Estimated Days Until OOM= 11.11
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.