Debugging Performance: How I Fixed an Async Memory Leak in Node.js

We've all been there: the code passes every unit test, the logic is flawless, but in production, the memory usage climbs like a mountain until the process crashes. Recently, I faced a "silent killer" in a Node.js microservice. Here is how I found and fixed it.

The Problem: The Creeping RAM

I was processing a large batch of API migrations using a simple forEach loop with async/await. On my local machine with 100 records, it was fast. In production with 100,000 records, the container kept hitting the 2GB RAM limit and restarting (OOM Error).

// What I thought was fine
data.forEach(async (item) => {
    await processItem(item); // This fired thousands of promises simultaneously!
});

The Discovery

The issue wasn't the processing itself, but concurrency control. By using forEach, I wasn't waiting for each promise to finish; I was spawning thousands of parallel operations, each holding a chunk of memory. Node's event loop was overwhelmed.

The Solution: Controlled Concurrency

I refactored the logic to use a "Worker Pool" pattern or a simple for...of loop to ensure sequential execution, or Promise.all with chunks to maintain speed without crashing the heap.

// The Fix: Processing in sequence or chunks
for (const item of data) {
    await processItem(item);
}

Key Takeaways

• Monitor the Heap: Use node --inspect to find where objects stay alive.
• Avoid forEach with Async: It doesn't respect the "await" keyword as you expect.
• Respect Limits: Always implement a limit to how many concurrent tasks your system can handle.

Have you ever faced a bug that only appeared under heavy load? Let's discuss in the comments!