Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the memory increase quickly, when log too frequently #181

Closed
Bo101010 opened this issue Feb 13, 2014 · 12 comments
Closed

the memory increase quickly, when log too frequently #181

Bo101010 opened this issue Feb 13, 2014 · 12 comments
Milestone

Comments

@Bo101010
Copy link

the memory increase quickly, when log too frequently. I can understand it. But when i turn down the frequency the log while the process is running, the memory do not reduce. I think log4js should fush the buffer to reduce.But,wy?

@amirivija
Copy link

+1

@ozkozk
Copy link

ozkozk commented May 10, 2015

I have a similar issue with long runs of my system. After a while, log4js stops dumping to file and only stores in memory. Memory consumption starts going up pretty quickly and nothing is flushed to the file. I'm using version 0.6.22 if that matters, but couldn't find anything that says something like that was fixed recently...

@chosenvictim
Copy link

+1
I have a log server which writes large number of log lines to file. I am also getting memory leaks in the writeStream.
My Nodejs version is 0.10.37

@thelonglqd
Copy link

+1

@royalrover
Copy link

I have the same question.

@bholbrook73
Copy link

+1

@nomiddlename
Copy link
Collaborator

Can anybody supply a bit of code that reproduces the issue? Not everyone has the same definition of "large number of log lines", or "long runs of my system", so it would be good to know some numbers as well. It sounds like there's definitely a memory leak, but I'd like to be able to be sure when it's been fixed.

@blakambr
Copy link
Contributor

blakambr commented Oct 19, 2016

+1 same issue here. Have been able to reproduce it with the following code:

var log4js = require('log4js');
var logger = log4js.getLogger();

// log every 30ms
var tid = setInterval(function () {
  logger.debug();
}, 30);

// stop after 30s
setTimeout(function() {
  clearInterval(tid);
}, 30000);

Am using the following tool node-inspector to analyse the heap dumps which seems to grow at ~2MB every 10 seconds. Once the logging stops, the heap size remains constant which leads me to believe that something isn't getting flushed.

NodeJS v4.4.7 using log4js@0.3.8

@nomiddlename
Copy link
Collaborator

Thanks for that @blakambr - very helpful.

@nomiddlename
Copy link
Collaborator

Looks like, in your example anyway, that the problem is in the use of console.log in the console appender. If I add the following configuration line to your script, the increasing heap doesn't happen.

log4js.configure({
  "appenders": [
    { "type": "stderr", layout: { type: "messagePassThrough" } }
  ]
});

The stderr appender just uses process.stderr.write. I'll replace the call to console.log in the console appender with process.stdout.write and see what happens.

@nomiddlename
Copy link
Collaborator

Replacing the call to console.log with process.stdout removes this memory issue. Looks like it is due to this long-standing problem in node.js. But I don't think this is the same issue as others are reporting (some mention they are writing to a file), but without seeing their configuration I can't really tell. I'll fix this up anyway.

It's possible to reproduce this using the following code, which shows it isn't log4js that is the problem:

var tid = setInterval(function () {
  console.log('');
}, 30);

// stop after 30s
setTimeout(function() {
  clearInterval(tid);
}, 30000);

@nomiddlename nomiddlename added this to the 1.0.0 milestone Nov 3, 2016
@nomiddlename
Copy link
Collaborator

This should be fixed in version 1.0.0, which uses the stdout appender instead of the console one as default. If you're explicitly using the console appender in your config, you'll need to change it to stdout to see any benefit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants