retained and not made reclaimable by the garbage collector 2. Frequent old-space object movement causes frequent old-space collections, which introduce pauses 3. Allocation pressure causes very frequent scavenge collections and potentially old-space collections if objects are promoted 4. GC consumes a lot of CPU cycles that should be available to the application 5. Out-of-memory conditions occur if old-space limit is exceeded (not necessarily related to OS maximum commit size)
policies • Unneeded references from observers or callbacks • Especially common with timers, e.g. setInterval callback that needs access to a large cache of objects • Infinite lists of closures [Meteor issue]
memory leak Sweep (vs. compact) or low GC rates can mislead you into thinking there is a leak when there isn’t one 2. Capture multiple heap snapshots over time A heap snapshot contains heap objects and references between them 3. Find the delta between consecutive snapshots Which objects are being added to the heap and not removed? 4. Determine why the extraneous objects are not freed Which reference chain is responsible for retaining these objects?
use the v8-profiler module or the heapdump module • v8prof.takeSnapshot().export(…) • heapdump.writeSnapshot() • Can trigger snapshots on SIGUSR2 (kill -USR2 `pidof node`) • Snapshots are simple JSON documents with all the nodes and edges in the heap • Can also use memwatch to get an automatic snapshot diff from within the process