Can You Really Let a Memory Leak Run? Practical Insights and Risks

NPI‑GC in high‑requirement software

Some military missile software uses a technique called NPI‑GC, provisioning extra memory to cover the maximum leak expected during flight. The system is given roughly twice the estimated leak amount, and the leaked memory is reclaimed when the missile is destroyed.

GitLab Sidekiq memory‑leak mitigation

Sidekiq processes start with >200 MB RSS and can grow due to Ruby/Rails memory leaks. GitLab mitigates this by running multiple Sidekiq workers and a memory‑killer that terminates any worker whose RSS exceeds a configured threshold.

sidekiq['concurrency'] = 4          # maintain 4 Sidekiq processes
sidekiq['memory_killer'] = true    # enable killer
sidekiq['memory_killer_max_rss'] = 2000000  # kill when RSS > 2000 MB

The memory usage graph shows a sharp drop when a worker is killed, followed by a rapid rise as a new worker starts, producing a repeating cycle. GitLab’s minimum recommended RAM (8 GB) mainly provides headroom for this growth; without leaks, a smaller allocation would suffice.

Operational experiences with scheduled restarts

In several projects, uncontrolled leaks caused services to exhaust RAM after days, leading to crashes during peak periods. Operators mitigated the issue by scheduling daily restarts (e.g., 07:00) and persisting session data before the restart.

Linux OOM‑killer and oom_adj

When system memory is low, the kernel’s OOM‑killer selects a process to terminate. The selection priority can be adjusted via oom_adj, ranging from –17 (least likely) to 15 (most likely). To protect a critical process:

echo -17 > /proc/<pid>/oom_adj

Summary of feasibility

Allowing memory leaks and relying on periodic restarts or kill mechanisms can work in controlled environments where sufficient memory is provisioned and the impact of a killed process is acceptable. However, this adds operational complexity and may be unsuitable for high‑availability production systems.