How to find out *if* there is a memory leak?

[Felix E. Klee]

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.

[Felix E. Klee]

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-js-a-node-js-holiday-season/>

[Ben Noordhuis]

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.

[Felix E. Klee]

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

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

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.

[Stefan Zehe]

Am 19.11.2012 16:41, schrieb Ben Noordhuis:
> Keep an eye on RSS. If your application is at equilibrium but RSS
> keeps growing indefinitely, chances are good there is a memory leak.

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?

[Felix E. Klee]

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

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

> [...]

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

[Joel Rolfe]

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

[themitchy]

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

[Felix E. Klee]

On Wed, Nov 28, 2012 at 6:16 PM, themitchy <mi...@nodefly.com> wrote:
> If this post-gc value continues to increase, you likely have a memory
> leak.

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

[themitchy]

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

[Felix E. Klee]

On Tue, Nov 27, 2012 at 9:26 PM, Joel Rolfe <jro...@gmail.com> wrote:
> 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

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