3 ms·

console.log entries in Node.js does not get garbage collected

15 points by theogravity 8y ago

theogravity 8y ago
One of the services we develop has been in a state where we can now look at performance and memory optimizations. I've been investigating memory pressure issues using the node inspect tools (which interfaces with the Chrome memory profiler). I noticed that the default stream for console.log in node.js does not get garbage collected, and raised an issue about it in the github node org, where a node dev has acknowledged the behavior. He provided a link to a larger thread where this is being discussed, but it seems it's been in discussion since 2016. One possible solution around this is to write log entries to a file instead of using the default stream.
- theogravity 8y ago
  Update: Via bnoordhuis (Ben Noordhuis - node.js dev): I see you posted this over at https://www.reddit.com/r/node/comments/8s2y7b/til_consolelog_entries_will_not_get_garbage/ https://www.reddit.com/r/node/comments/8s2y7b/til_consolelog... but your summary there is wrong. You should update it because it's going to mislead others. The state of things: A connected inspector client will cause console.log() to buffer a bounded number of messages (currently 1,000.) Libuv can buffer messages when you print faster than the sink (tty, pipe, file, etc.) can consume them. That's something you can fix by pacing your writes.
alexgvozden 8y ago
as you saw in comments this is needed for logging purposes for example in DevTools, it keeps certain number of logs in memory for debugging purposes I would not recommend console.log for production anyway
theogravity 8y ago
Reddit discussion here (with lots of good tips / info): https://www.reddit.com/r/node/comments/8s2y7b/til_consolelog_entries_will_not_get_garbage/ https://www.reddit.com/r/node/comments/8s2y7b/til_consolelog...
alexh1 8y ago
Ha, we ran into this a couple of weeks ago. Here [1] is a write up of what we found... our assumptions don't match up exactly with what is in the GitHub issue here but it was the best we could do. [1] https://tech.datawallet.com/posts/weekly-update-2018-06-01/ https://tech.datawallet.com/posts/weekly-update-2018-06-01/

15 points by theogravity 8y ago

One of the services we develop has been in a state where we can now look at performance and memory optimizations. I've been investigating memory pressure issues using the node inspect tools (which interfaces with the Chrome memory profiler). I noticed that the default stream for console.log in node.js does not get garbage collected, and raised an issue about it in the github node org, where a node dev has acknowledged the behavior. He provided a link to a larger thread where this is being discussed, but it seems it's been in discussion since 2016. One possible solution around this is to write log entries to a file instead of using the default stream.

theogravity 8y ago
Update: Via bnoordhuis (Ben Noordhuis - node.js dev): I see you posted this over at https://www.reddit.com/r/node/comments/8s2y7b/til_consolelog_entries_will_not_get_garbage/ https://www.reddit.com/r/node/comments/8s2y7b/til_consolelog... but your summary there is wrong. You should update it because it's going to mislead others. The state of things: A connected inspector client will cause console.log() to buffer a bounded number of messages (currently 1,000.) Libuv can buffer messages when you print faster than the sink (tty, pipe, file, etc.) can consume them. That's something you can fix by pacing your writes.

alexgvozden 8y ago

as you saw in comments this is needed for logging purposes for example in DevTools, it keeps certain number of logs in memory for debugging purposes I would not recommend console.log for production anyway

theogravity 8y ago

Reddit discussion here (with lots of good tips / info): https://www.reddit.com/r/node/comments/8s2y7b/til_consolelog_entries_will_not_get_garbage/ https://www.reddit.com/r/node/comments/8s2y7b/til_consolelog...

alexh1 8y ago

Ha, we ran into this a couple of weeks ago. Here [1] is a write up of what we found... our assumptions don't match up exactly with what is in the GitHub issue here but it was the best we could do. [1] https://tech.datawallet.com/posts/weekly-update-2018-06-01/ https://tech.datawallet.com/posts/weekly-update-2018-06-01/