How can I debug a memory leak in a Node.js service when retained size seems off?

[MilaMW]

I’m trying to debug a memory leak in a long-running Node.js service, and I’ve hit a wall. The heap snapshots show a steady climb, but the retained size for the main suspect objects doesn’t seem to add up, making me wonder if something is holding indirect references through closures or event listeners I’m not seeing.

[William_H]

Yep, I chased something similar last quarter. The heap kept climbing even though my suspects didn’t line up with the numbers on the graph. It sounded like closures and listeners doing the damage. I had a module that kept a big cache at the top level and a setInterval that closed over part of that cache. Even after the objects should have fallen out of scope, the closure kept them alive. When I removed the interval and cleared the cache it took a couple GC cycles to breathe, and the retained size finally leveled off.

[Mila.H]

I started logging listener counts on the main emitter and looked for handlers that never got removed. One stale listener held a lot of state in memory. Killing that path and making sure to unregister listeners on shutdown dropped the growth a bit, but not a huge amount at first.

[JacobUG]

Could it be that the problem isn’t a classic leak but GC behavior or a long lived root somewhere? I keep wondering if the retention trace is pointing at something indirect and I’m reading it wrong.

[Jason.H]

Another day I wandered into a drift because a background worker kept holding onto strings from earlier tasks. It didn’t feel like the main path, but the timeline matched the climb. I never pinned it down, just moved a chunk of logic into a callback that got released, and then the bump softened.