My Node.js server crashed every midnight with 'Heap Out of Memory'. The culprit? A global variable hoarding data. Through this debugging nightmare, I learned the true difference between Stack and Heap, how V8 Garbage Collection works, and how to prevent memory leaks.
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.
Two ways to escape a maze. Spread out wide (BFS) or dig deep (DFS)? Who finds the shortest path?
Fast by name. Partitioning around a Pivot. Why is it the standard library choice despite O(N²) worst case?
Establishing TCP connection is expensive. Reuse it for multiple requests.
I had a strange issue with a Node.js server I was maintaining last year. It ran perfectly fine during the day, but restarted every night at 12 AM. (Like Cinderella). The logs revealed a horrific message right before death:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
"Out of memory? But the AWS instance has 16GB of RAM!" It turned out the RAM usage from the OS perspective was fine, but the V8 Heap limit was reached. Node.js (before v12) had a default heap limit of about 1.4GB. My app was hitting that ceiling.
This incident forced me to open the black box called "Memory" and understand what was happening inside.
Where do variables go when we write code? Mainly into two places: Stack and Heap.
Here is the easiest analogy for non-CS majors.
int, boolean, double.free() in C/C++, Garbage Collector in Java/JS/Python).Object, Array, Map.My server died not because of the Stack, but because of the Heap. Stack memory is automatically reclaimed when functions return. But Heap memory depends on your logic.
Looking at the code, the culprit was trivially simple yet devastating.
// The Suspect
const requestLogs = []; // Global Variable (Stored in Heap)
app.use((req, res, next) => {
// Pushing data on every request
requestLogs.push({
url: req.url,
time: Date.now(),
headers: req.headers // Headers can be surprisingly large
});
next();
});
I thought, "Let's keep some logs in memory for debugging." That global array requestLogs was the problem.
This array lives in the Heap.
Every request added data to it, but no one ever emptied it.
req, res) disappear after the response is sent.requestLogs) survive as long as the process lives.This brings us to the crucial concept of "Reference". The Stack only holds the address (sticky note), while the actual data sits in the Heap (warehouse).
let user = { name: "Ratia" };
{ name: "Ratia" }. (Address: 0x1234)0x1234 on the variable user.What if we do user = null?
The sticky note on the Stack is wiped.
But { name: "Ratia" } inside the Heap remains.
This is when the janitor, Garbage Collector (GC), comes in. It scans the warehouse.
"Hey, does anyone have the receipt for this box (0x1234)?" "No? Okay, it's trash. Burn it." (Deallocation).
In my failed code, the requestLogs global variable kept holding references to the log objects.
So the GC thought, "Ah, this data is still needed because requestLogs refers to it," and refused to clean it.
This is a Memory Leak. You are hoarding trash because you forgot to tell the janitor it's trash.
Imagine a library.
My code was effectively doing this: Every time a user visited, I took a book, wrote a log in it, and put it on a shelf. But I never threw old books away. Eventually, the shelves were full. The librarian (V8 Engine) tried to make space (Mark-and-Sweep GC), but every book was marked as "Important" because the global array referenced them. The librarian panicked ("Ineffective mark-compacts") and finally collapsed ("Fatality").
The solution was simple. Don't use application memory (Heap) for logs. Use disk (File) or external storage (Redis/Elasticsearch).
// Solution: Write to file using Stream (Don't use Heap)
const fs = require('fs');
const path = require('path');
// Create a write stream
const logStream = fs.createWriteStream(path.join(__dirname, 'access.log'), { flags: 'a' });
app.use((req, res, next) => {
// Writes directly to file buffer, minimal memory footprint
logStream.write(`${new Date().toISOString()} ${req.url}\n`);
next();
});
After this change, the Heap memory usage flattened out, and the server never crashed again. If you must use in-memory storage, always limit the size (e.g., Circular Buffer).
While my issue was Heap Overflow, what is Stack Overflow? It happens when you pile too many sticky notes on your desk.
function recurse() {
recurse(); // Calls itself forever
}
recurse();
Each function call adds a Stack Frame. Since the Stack size is fixed per thread (usually around 1MB), infinite recursion fills it up instantly. Unlike Heap issues which are slow and insidious (leak over days), Stack issues are immediate and usually caused by logical bugs in recursion.
With modern languages like JS, Python, or Go, you can develop without manually managing memory (malloc/free).
But "You don't have to manage it" does NOT mean "You don't have to worry about it."
There might be a monster (Memory Leak) growing in your server right now, waiting for midnight. Check your monitoring dashboard today.