These are my notes from a talk on July 3, 2012 at NodeConf given by Jed Parsons, @drainmice on twitter.
Memory Leaks - So What?
As heap size grows, V8 becomes sluggish. Before you run out of memory, if you're holding onto file handles or connections to Redis, you can run into nasty surprises right when you become popular. Tragic and horrible! You want to find them and eliminate them.
JS closures are kind of notorious as sources of leaks, and it can get tricky to track things down. The streams session earlier talked a lot about backpressure. You may not be allocating memory that can never be reallocated or released, maybe it just can't be reallocated or released soon enough. So things that aren't really leaky code start to behave like leaky code. It's also possible that there are are all kinds of sources for leaks.
One that hit BrowserID when we were load-testing was a one-line change in node core from .on() to .once().
The goal of node-memwatch is to have a platform-independent debugging library requiring no instrumentation that can alert us when our programs might be leaking memory, and help us find where they are leaking. The API will provide three things:
- An on-leak emitter
- An on-GC stats emitter
- A heap diff class
Node provides the process.memoryUsage() function, but as people have mentioned this doesn't give you a great idea of what's going on. V8 has this neat V8:AddGCEpilogueCallback. Our API gives you a stats event any time garbage has been collected. (Full garbage collection and heap compaction.)
You have a leak detector; finding the leak is the harder part. By comparing successive heap snapshots we can produce a heap diff.