performance-observabilityAnswer last reviewed July 2026

Say memory on one of your Node services just keeps climbing in production. How would you dig into that without bouncing the process?

A strong answer keeps RSS, heapUsed, and external memory straight, and can chase a production leak without ever bouncing the process

What an AI-prepared candidate might say

I'd start with process.memoryUsage() and look at which number is actually growing. RSS is the total resident memory the process is holding. heapUsed is how much of the V8 heap is in use, and external is memory from C++ objects bound to JavaScript, Buffers mostly. If heapUsed keeps growing it's probably a JavaScript leak, objects being retained that should have been collected. So I'd take heap snapshots at intervals and compare them in Chrome DevTools to see what's piling up. Usual suspects are unbounded caches, event listeners nobody removed, closures holding references, that kind of thing. If it's external that's growing, that points at Buffers or native memory instead. Basically look at what allocates over time and whether the references ever get released, then fix whatever code is holding them. Restarting just masks it, so the goal is finding the actual retention.

Senior
Locked

What RSS, heapUsed, and external each actually measure, why a Buffer leak will never show up in heapUsed, and how you tell a growing retained set from normal churn.

Unlock the depth
Staff
Locked

How to capture comparable heap snapshots off a live process, read the diff for the retaining path, and tell a real leak apart from GC that just hasn't run yet.

Unlock the depth
Follow-up chain
Say memory on one of your Node services just keeps climbing in production. How would you dig into that without bouncing the process? | NodeBook