Node.js Memory Mystery: Developer Investigates 400 MiB Memory Bloat in Production Pods
Key Takeaways
- ▸Memory growth occurred in discrete jumps during fetch bursts, not gradually, indicating aggressive allocation patterns
- ▸All 406 MiB of extra memory was in private dirty anonymous memory (malloc/mmap allocations), not in V8 heap as initially suspected
- ▸The investigation used system-level tools (smaps_rollup, V8 Inspector via SIGUSR1) to isolate the memory consumer within a complex container environment
Source:
Summary
A developer investigating unexpected memory bloat in production Node.js websocket application pods discovered a 400 MiB discrepancy between a healthy pod (~330 MiB) and a problematic one (~640 MiB). Using process memory analysis tools like smaps_rollup and the V8 Inspector, they traced the issue to private dirty anonymous memory rather than typical JavaScript heap growth. The investigation revealed discrete memory jumps during message fetch bursts rather than gradual climbs, suggesting the memory allocations were never being released back to the operating system. The findings point toward deeper issues in how V8 manages memory and how the underlying system allocates and fragments memory regions.
- One pod receiving heavy automation traffic showed permanent memory retention while identical pods with lighter load remained stable
