How to Fix a Node.js Memory Leak

Why the heap keeps climbing

Node.js processes are long-lived. Any collection you allocate at the module level and never clear accumulates entries for the entire lifetime of the process. Under production traffic - thousands of requests per hour - an unchecked global array goes from harmless to hundreds of MB in hours.

The classic shape looks like this:

const requests = [];   // global - lives forever

server.on('request', (req) => {
  requests.push({ url: req.url, ts: Date.now() });
  // nothing ever removes entries
});

After 24 hours of normal traffic, requests holds millions of entries. The heap grows linearly with uptime - the textbook sign of an unbounded collection.

Find the leak

Before touching code, confirm WHERE memory is growing. Two fast approaches:

• /stats endpoint - if the app exposes a count, watch it climb: curl localhost:3000/stats
• process.memoryUsage() - log heapUsed on a timer to see steady growth with no plateau

A heap that never stabilizes between requests points to a module-level collection. Scan your top-level code for any const arr = [] or const map = new Map() that is appended to in a request handler.

Cap the collection with .shift()

The simplest fix is a length cap. After each push, drop entries from the front until the array is back inside the limit:

const requests = [];
const MAX_REQUESTS = 100;

server.on('request', (req) => {
  requests.push({ url: req.url, ts: Date.now() });
  while (requests.length > MAX_REQUESTS) requests.shift();
  // array never exceeds 100 entries - O(1) memory
});

Memory growth is now O(1) regardless of traffic volume.

Alternative: time-based pruning

If you need "last N seconds" rather than "last N entries", prune by timestamp:

const WINDOW_MS = 60_000; // keep the last 60 seconds

server.on('request', (req) => {
  const now = Date.now();
  requests.push({ url: req.url, ts: now });
  // drop entries older than the window
  while (requests.length && requests[0].ts < now - WINDOW_MS) {
    requests.shift();
  }
});

Verify the fix

After applying either fix, run a load test and watch /stats:

bash /workspace/load-test.sh       # send 1000 requests
curl -s http://localhost:3000/stats  # should plateau at <= 100

The count should hit the cap and stay flat, not keep climbing.

In production: go deeper

• clinic.js / heapdump - generate a V8 heap snapshot to confirm the allocation site when the leak isn't obvious from a quick scan.
• lru-cache or node-cache - a proper LRU or TTL cache handles eviction automatically and is safer for shared caches than a hand-rolled shift loop.
• Heap metrics - expose process.memoryUsage().heapUsed to your monitoring system; alert before the process hits its memory limit.