v8-memoryAnswer last reviewed July 2026

Here's a scenario. Memory keeps climbing in production until the pod restarts, and you can't reproduce it locally. How do you actually find the leak?

You can tell a strong answer because they've actually walked a retainer path in a snapshot diff and know what a snapshot costs on a big live process

What an AI-prepared candidate might say

I'd go with heap snapshots. Take one snapshot, let the process run and grow for a while, take a second one, and then use the comparison view in Chrome DevTools to see which object types grew between the two. If I can't attach DevTools, there's v8.writeHeapSnapshot() or the inspector protocol to dump snapshots to disk. Once I can see what's accumulating, strings or closures or some specific class, I'd look at its retainers to find whatever's holding it. Usually it's a cache with no eviction, or event listeners getting added over and over and never removed, or closures capturing large data. Since it only shows up in production, I'd try to reproduce it under realistic load in staging, or maybe snapshot a production instance carefully. And I'd watch process.memoryUsage() over time to confirm it's really heap growth and not something else.

Senior
Locked

The three-snapshot diff workflow, how you actually read a retainer path back from a GC root, and the handful of leak shapes behind most real incidents.

Unlock the depth
Staff
Locked

How snapshotting a hot pod turns a debugging session into an outage, the near-heap-limit and canary tricks that work instead, and the trend monitoring that catches leaks before anyone gets paged.

Unlock the depth
Follow-up chain
Here's a scenario. Memory keeps climbing in production until the pod restarts, and you can't reproduce it locally. How do you actually find the leak? | NodeBook