How to Detect and Fix Node.js Memory Leaks: V8 Insights and Practical Tools

V8 Memory Limits

Node runs on V8, which limits old generation memory to about 1.4 GB on 64‑bit systems and new generation to about 32 MB. Exceeding these limits can cause process exit.

Reason: V8 performs stop‑the‑world garbage collection; a full GC on a 1.5 GB heap can take >50 ms, non‑incremental GC may take >1 s.

Adjust limits with node --max-old-space-size=… and node --max-new-space-size=….

V8 Heap Structure

The heap consists of several regions:

New generation: small, frequent GC.

Old generation pointer space: holds objects with pointers, receives promoted objects.

Old generation data space: stores raw data objects without pointers.

Large object space: stores objects larger than other spaces, not moved by GC.

Code space: contains JIT‑compiled code, the only executable memory region.

Cell, Property Cell, Map spaces: store cells, property cells, and maps of uniform size.

GC Types

Incremental GC collects garbage while scanning and clears it at the end of the cycle. Non‑incremental GC clears garbage immediately when found.

GC runs on new generation, old generation pointer and data spaces. Objects start in the new generation; if they survive, they move to old generation where incremental GC runs less frequently and takes longer.

How Memory Leaks Occur

Common causes include:

Unreleased caches.

Queues not consumed promptly.

Scopes that are not freed.

Analyzing Memory Usage

Key metrics (bytes):

rss : resident set size.

heapTotal and heapUsed : V8 heap information.

System memory can be inspected with OS tools; GC logs reveal collection events.

Monitoring tools:

v8‑profiler – heap snapshots and CPU profiling.

node‑heapdump – capture V8 heap snapshots.

node‑mtrace – stack usage analysis.

node‑memwatch – watch GC events.

stats event – emitted after a full heap GC with memory stats.

A leak event fires when memory is not released after five consecutive GCs, indicating a leak.

Practical Example

The article demonstrates a simple leak by continuously pushing objects into an array that never gets freed. Using heap-dump to record snapshots and Chrome DevTools Profiles to compare them shows the LeakClass size growing steadily, confirming the leak.

Summary

Detect leaks by integrating memwatch or periodically reporting process.memoryUsage() with alerts. When a leak is suspected, generate heap dumps locally with node‑heapdump and analyze them in Chrome Profiles, or on a test server use v8‑profiler to compare JSON snapshots. Choose monitoring frequency carefully to avoid CPU overload, and differentiate true leaks from short‑term memory spikes.