How do I find out if (not where) there is a memory leak in an app?

Background: I am using Socket.IO for client/server communication, and I
want to make sure that server side resources are properly cleaned up
when a connection is closed (`disconnect` event). Memory usage should be
proportional (plus a constant) to the number of connections. It should
not increase when reloading the app in the browser.

Just found a promising article (didn't read it yet), just some days old:

<https://hacks.mozilla.org/2012/11/tracking-down-memory-leaks-in-node-...>

On Sun, Nov 18, 2012 at 11:21 AM, Felix E. Klee <felix.k...@inka.de> wrote:

A quick and fairly reliable approach is to start node with --expose-gc
and call gc() every few seconds, like so:

  $ cat test.js
  if (typeof gc === 'function') setInterval(gc, 5000);
  require('./main.js'); // your main application

  $ node --expose-gc test.js

Keep an eye on RSS.  If your application is at equilibrium but RSS
keeps growing indefinitely, chances are good there is a memory leak.

The reason that you need to call gc() is that the garbage collector is
lazy.  It won't collect garbage until it's forced by sheer memory
pressure - and even then it may opt to grow the heap, not sweep it.

On Mon, Nov 19, 2012 at 4:41 PM, Ben Noordhuis <i...@bnoordhuis.nl>
wrote:

I like this approach, simple and light weight! Only probably it is not
enough to be on the safe side:

At least on WinXP, I see quite some fluctuations of the "Private Bytes"
as reported by Process Explorer for `node.exe`. Of course, I can see the
memory usage go up when there are more connections, and it fortunately
goes down when connections are closed. However, due to the fluctuations
it is hard to tell if some bytes are leaking on every closed connection.

Perhaps, I'll try on Linux later.

Am 19.11.2012 16:41, schrieb Ben Noordhuis:
Is js-code responsible for RSS memory leaks or only for the heap-growing
ones?
if both are js-code-caused, can someone give a code-example on how to
leaks rss and heap?

On Mon, Nov 19, 2012 at 4:41 PM, Ben Noordhuis <i...@bnoordhuis.nl>
wrote:

With [memwatch][1] something similar can be done:

    $ cat test.js
    'use strict';

    var memwatch = require('memwatch');

    memwatch.on('stats', function (stats) {
        console.log('current base:', stats.current_base);
    });

    setInterval(memwatch.gc, 5000);

    $ node --expose-gc test.js
    current base: 1217308
    current base: 1217512
    current base: 1371772
    current base: 1373436

Again I do see fluctuations; haven't investigated that yet.

[1]: https://github.com/lloyd/node-memwatch

I just put the following together on monitoring memory, and finding memory
leaks.  Very memwatch centered.  Hope it helps:

http://code.osnap.us/wp/?p=43

NodeFly gives you a chart of Heap Usage and RSS.  There is also a chart of
Heap size calculated after each full garbage collection cycle.  If this
post-gc value continues to increase, you likely have a memory leak.  
NodeFly beta is free to use: http://www.nodefly.com

-mitch

Doesn't make sense to me. I expect that value to fluctuate with the
number of client (browser) connections.

Number of connections is definitely part of the story.  NodeFly also
provides graphs of concurrent connections and throughput.

A fuller story might be: If your post-gc heap size goes up but your
connection count has not, then you may have a memory leak.

-mitch

Thanks - that seems very helpful. Just left a comment.