Chasing Down a Slow Memory Leak in Node or Go Before It Pages You

Rising memory usage on its own isn't proof of a leak; both Node's garbage collector and Go's runtime naturally hold onto some memory for efficiency, and usage that climbs then plateaus at a stable level is normal, healthy behavior. A real leak shows a memory graph that keeps climbing without ever plateauing, over a timeframe long enough to rule out normal garbage collection cycles or cache warm up.

Watch the growth pattern against traffic, not just against time. Memory that grows in proportion to request volume and then comes back down when traffic drops is a sign of a working cache or connection pool, not a leak; memory that keeps climbing even during a quiet period with steady low traffic is the pattern actually worth investigating.

Signs that rising memory is a real leak:

• Memory keeps climbing without ever plateauing, over a timeframe long enough to rule out normal garbage collection cycles or cache warm up.
• Usage keeps climbing even during a quiet period with steady, low traffic.
• Growth that tracks request volume and comes back down when traffic drops points to a working cache or connection pool, not a leak.
• Usage that climbs and then plateaus at a stable level is normal, healthy behavior, so rule that pattern out first.

Capture a heap snapshot early after the process starts, let the suspected leak accumulate under realistic load for a meaningful stretch of time, then capture a second snapshot and compare the two directly rather than examining either one in isolation. The comparison view highlights what grew between the two snapshots, which narrows the search dramatically compared to reading a single snapshot's full object graph.

Pay close attention to objects retained by a closure or an event listener that was never removed, since an event emitter that accumulates listeners over time without ever unsubscribing them is one of the most common real leak patterns in a long running Node service, and it shows up clearly as a steadily growing count of listener objects in the comparison view.

Go's pprof tooling profiles heap allocations directly, and the same two point comparison approach applies: capture a profile early, let the process run under load, capture a second profile, and diff them to see what's actually accumulating rather than what's simply allocated. The diff view sorts by the objects contributing the most growth, which is usually where the actual leak lives.

A goroutine leak, goroutines started but never exiting, is a distinct and common Go specific failure mode worth checking separately from heap growth, since a goroutine that blocks forever on a channel that's never written to holds its stack memory indefinitely. pprof's goroutine profile, not just its heap profile, is the tool for catching this specific pattern, and a steadily climbing goroutine count over time is as strong a signal as climbing heap memory.

Once you've found the accumulating object, the fix is usually straightforward, unsubscribing a listener, closing a channel, clearing a cache with unbounded growth, but verify the fix with the same two snapshot comparison method rather than assuming the code change worked. It's a genuinely common mistake to fix the specific leak that was found while introducing a slightly different one in the same area of code during the fix itself.

Add the leak scenario to your regular test suite if it's practical to reproduce, running the code path in a loop and asserting memory stays within a reasonable bound. This catches a regression the next time someone touches that code, rather than waiting for the leak to reappear in production months later and having to rediscover the whole diagnosis from scratch.