Just noticed mine is using 6.3 gig, is this normal? I have the DL5 one running too and its using 100 meg.
beta 14 win7 64bit
Nope, that’s definitely not normal (unless you have 500,000 jobs in your queue). Just a couple questions:
- How many jobs and slaves do you have showing in the Monitor?
- How long was the Monitor running for?
- If you restart the Monitor, do you notice a gradual memory usage climb?
It sounds like there is a leak somewhere. Just need to figure out if it’s a gradual thing, or if the Monitor all of a sudden explodes with huge memory usage.
We have only about 50-100 jobs on there.
On open monitor starts at around 150 meg then it just creeps up… its now at 250 since I have been typing 
Its happening on other users machines as well.
I shut down my monitor every night so It would have only been running for 6 hours to get to 6GB.
Ill check some other uses to see if everyone is getting it.
edit:
up to 2.5Gig after 30 min. Same rate with other users.
Ok, this might help:
If I open deadline through a shorcut to the exe, the memory gradually increases forever.
If I open it through launcher (which isn’t as convenient since I’m still running the DL 5 monitor) it seems fine.
I’ll check whether the other guys have the same behavior.
cheers,
grant
Ignore that post. On my machine it seemed to delay the start of the memory being consumed, but it happens regardless.
cheers,
grant
Just to add to the confusion, I’m now running beta 15 just for monitor and it seems to have sorted me out. But Jordans machine not so, about says 50661 and just killed it at 2 gig of ram usage.
cheers,
grant
Thanks for the additional info. Definitely sounds like a gradual leak.
Jordan, which panels do you have open in the Monitor? I’m wondering if the leak is specific to certain panels, and that’s why you see it on your machine but Grant doesn’t see it on his.
Thanks!
- Ryan
I had jobs, tasks slaves and limit groups open.
I tried reverting to the default layout and still getting the issue.
Tried only jobs, tasks, slaves and LGs by themselves and the memory is still increasing.
Thanks Jordan.
We’ve logged this issue as a bug, and we’ll try to reproduce and track it down.
Cheers,
- Ryan
Any luck with this? Just installed beta 17, and it’s doesn’t take more than a few minutes to progressively eat gigs of memory.
It’s not just a few workstations that have this problem, but pretty much all of them. Not sure what it is about our setup that means we all see it but not other studios. We have over 330 slaves in the slave list in case it’s being tested against a smaller set. Not sure what else we are doing differently.
cheers,
grant
As a test, I installed a new repository pointing to a new Mongo db (local to my machine was the easiest).
Opening a monitor pointing at this new empty db, no memory leak.
If in the same monitor session I point it at our live db, it starts eating memory (note that I’m not actually doing anything in the UI - I just change the repository setting and wait).
Set it back to the local db, it dumps a ton of Ram, and stops eating memory.
Back to the networked production db, back to eating memory.
Would there be any value in you trying our db? It’s 4 meg in size, I could probably just email it (.tar.gz)
I’m likely going to rebuild the database from scratch too see if that helps, though it isn’t very old (initially beta 13 or so).
cheers,
grant
Hi
Did a little mongoexport/mongoimport to rebuild our db in a new location (super easy to transfer settings via .json files, very nice).
What I’ve found is that if I import everything - including jobs, etc. - the new DB has the memory leak so it isn’t some old data setup.
If I then simply remove SlaveSettings and reimport a modified json file that has just one slave entry, no memory leak.
Run the import to import the original set, and it starts leaking memory again.
You might be able to build a fake slave list and import that, as these slaves aren’t actually connected to anything using this DB, or I can email the .json files through if you want the SlaveSettings (and maybe the SlaveReports file too - just about to check if clearing out the reports makes any difference).
cheers,
grant
Hey Grant,
If you can upload the test database here, or zip it up and email it to me directly, that would be great! That’s very interesting to know that it’s related to the SlaveSettings collection, and that should be a big help in tracking this down.
Thanks!
- Ryan
Hey Grant,
We took a clean repo with a bunch of slaves, and updated their settings so that each contained 2 pools, 2 groups, and a description and comment, and so far we haven’t seen any leaking. So there must be something specific about your SlaveSettings collection.
So if you can get me a dump of your database, we’ll test against it as soon as possible and try to reproduce.
Thanks!
- Ryan
Thanks. I’ve emailed you the json files along with the .bat files I was using to rebuild our mongo database, hopefully it’ll repro for you too - all our workstations have the problem.
cheers,
grant