javascript memory leak?

[mainmachine]

First off, this works brilliantly for us as a local DNS solution, for forwarding, caching and local name resolution. Thank you for your efforts!

The only issue I've encountered is that if I keep a tab open in Firefox with the web interface running, it will begin to eat RAM like a monster, and I usually get a firefox prompt "a web page is slowing down your browser" and a choice of "stop script" or "wait", which works by (you guessed it) stopping the JS on that tab. Memory is released and all is well, and as expected the log pane of webproc stops updating.

Now maybe my issue is the sheer volume of data being updated, as it's the DNS logs for our entire LAN. If that's the case, then it's not really a big deal. I've only kept the tab pinned while configuring for a couple of weeks, I don't really need to see the constant flow of DNS logs.

If there was a way to stop it from consuming so much RAM, I would assume by refreshing the data displayed, or something like that, it would be a good thing. I can imagine there will come a time when I may need to consult the logs to diagnose issues on the network, fixing this would make that easier.

My machine is no slouch, I've got 16GB RAM, an i7 with 8 threads, running Ubuntu-MATE 16.04.

I am not JS savvy enough to debug, otherwise I'd try to fix it myself. :(

[jpillora]

On latest image?

…

On Thu, 26 Apr 2018 at 2:36 am David Martinka ***@***.***> wrote: First off, this works brilliantly for us as a local DNS solution, for forwarding, caching and local name resolution. Thank you for your efforts! The only issue I've encountered is that if I keep a tab open in Firefox with the web interface running, it will begin to eat RAM like a monster, and I usually get a firefox prompt "a web page is slowing down your browser" and a choice of "stop script" or "wait", which works by (you guessed it) stopping the JS on that tab. Memory is released and all is well, and as expected the log pane of webproc stops updating. Now maybe my issue is the sheer volume of data being updated, as it's the DNS logs for our entire LAN. If that's the case, then it's not really a big deal. I've only kept the tab pinned while configuring for a couple of weeks, I don't really need to see the constant flow of DNS logs. If there was a way to stop it from consuming so much RAM, I would assume by refreshing the data displayed, or something like that, it would be a good thing. I can imagine there will come a time when I may need to consult the logs to diagnose issues on the network, fixing this would make that easier. My machine is no slouch, I've got 16GB RAM, an i7 with 8 threads, running Ubuntu-MATE 16.04. I am not JS savvy enough to debug, otherwise I'd try to fix it myself. :( — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmr82RqebEP43bsOVAB4J8ZIMFHxFBXks5tsKYbgaJpZM4TjxSZ> .

[jpillora]

You could try overriding the ENTRYPOINT and set webproc option --max-lines to 500 or something less than the default (5000).

[mainmachine]

Yes, latest image.

I'll try that and report back - sounds like this could be worth looking at...

[mainmachine]

OK, so I implemented your suggestion, adding
,"--max-lines","500"
after the exisiting config options for the entrypoint, and the container launched and operated OK, but it will still eat all my RAM if allowed, unless I kill the tab. I'm testing off hours, so as not to disrupt operations in the office, and to increase load I ran an nslookup in a loop just to keep the log moving (although I don't think this was entirely necessary, as there's still lots of DNS traffic, even in off hours).

The browser console shows tons of run.js:55 lines, so I guess that's the busy section of that script:

Let me know if there's anything else I can test. It's just an inconvenience at this point, but I would like to help get it fixed if I could.

[jpillora]

This issue actually belongs to https://github.com/jpillora/webproc so I'll create the issue there and take a look when I can, unfortunately I can't promise when however as I'm quite swamped with work which needs to take priority over my open source stuff

…

On Fri, 27 Apr 2018 at 14:07 David Martinka ***@***.***> wrote: OK, so I implemented your suggestion, adding ,"--max-lines","500" after the exisiting config options for the entrypoint, and the container launched and operated OK, but it will still eat all my RAM if allowed, unless I kill the tab. I'm testing off hours, so as not to disrupt operations in the office, and to increase load I ran an nslookup in a loop just to keep the log moving (although I don't think this was entirely necessary, as there's still lots of DNS traffic, even in off hours). The browser console shows tons of run.js:55 lines, so I guess that's the busy section of that script: [image: screenshot from 2018-04-26 23-57-28] <https://user-images.githubusercontent.com/12385366/39344166-d22a0990-49ae-11e8-9901-ad14e6299b1f.png> Let me know if there's anything else I can test. It's just an inconvenience at this point, but I would like to help get it fixed if I could. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmr8z4D4eSsmXXgjLT9_2_kxWrnZUXNks5tspl8gaJpZM4TjxSZ> .

[mainmachine]

Yup, when I first reported this I wasn't sure whether it was webproc or webproc+dnsmasq that was the issue. I'll close this and open an issue there.

Maybe I can convince someone on my team that works with JS to take a look. :)

Moved here.