Open zombieyang opened 8 years ago
droidenator
commented
8 years ago I'm seeing the same thing. Stats event fires without issue and even though my usage_trend is like..22 and memory usage has grown over 5+ GCs, the leak event is never fired.
marcominetti
commented
8 years ago @xosuperpig can you provide an example to generate a leak?
buptwinux
commented
8 years ago I have also run all of example, but the "leak" event could not triggered... just like this:
var hd;
memwatch.on('leak', function(info) {
console.log("leak:\n");
console.error(info);
if (!hd) {
hd = new memwatch.HeapDiff();
} else {
var diff = hd.end();
console.error(util.inspect(diff, true, null));
hd = null;
}
console.error('memory leak detected: ', info);
});
thank you very mach!
buptwinux
commented
8 years ago @droidenator , did your problem keep on？how solve it？
zombieyang
commented
8 years ago (function() {
var i = 0;
function run() {
return new Promise(function(resolve) {
if (i % 10000 === 0) console.log(process.memoryUsage());
i++;
setTimeout(function() {
if(i === 10000 * 10) return resolve();
resolve(run());
}, 0);
}).then(function() {});
}
run();
})();this is a Promise leak example in node 4.2 lts @marcominetti
joeytwiddle
commented
7 years ago I'm running node on a Mac Book Pro. I notice that garbage collection is sometimes running in pairs quite close together, and the second one reclaims a little bit of memory that the first did not.
As a result, my process never fulfils the "5 increases in a row" condition, despite the overall memory usage increasing!
Example log:
The leak is detected fine when I use slightly_leaky.js with i < 100000. But the above is when I drop the same setInterval() into my app. (The app is supposed to be idle!) So I guess it's something else going on in my app that throws off the detection.
I wonder if we could use a different condition for detection. Perhaps something like "over threshold T after 5 consecutive GCs" where T can be set manually, or perhaps chosen as "10 x the memory usage one minute after startup".
Notably the problematic gc pairs do not occur when I reduce the speed at which the leak grows, so perhaps I am just being too aggressive/impatient with my tests.
joeytwiddle
commented
7 years ago In the meantime, you can fake a 'leak' event like this...
memwatch.on('stats', function(d) {
// If the app is using more than 3GB RAM
if (d.current_base > 3000000000) {
// Either call your leak handling function directly:
// ...
// or manually trigger a 'leak' event, for what it's worth:
memwatch.emit('leak', { growth: d.current_base, reason: 'app using too much RAM lol' });
}
});hi @joeytwiddle, i'll delve into this on monday... ;)
egistli
commented
7 years ago @xosuperpig I modified the leaking http server in the example a bit and ran the http server for a while then memwatch did emit several leak events.
What I modified is to reduce the interval of leaking from 1000 to 10.
I've run all of the example, but no one could trigger this event...