Can someone who is still on Deadline 5 please tell me how much RAM the deadlineslave.exe is using during rendering? We’ve got a few old machines with just 8gb of RAM and they are experiencing even more of a bottle-neck than with Deadline 5.2, the Slave application is using 500mb of RAM and stalling (whiting out in windows) even though the task is 100% rendered the slave application isn’t responding due to max eating up all available Ram.
Obviously more Ram is the answer but I’m just curious to know if Deadline 6 is more RAM hungry than 5…
We have switched the last week to deadline and currently have Slaves where the deadlineslave.exe eats up to 10GB RAM. So I think Deadline6 have issues here yet. Who knows what this can be? Or do we have somewhere some strange settings?
I’m worried that we’re losing time with the Slave application stalling when the rendering has actually finished… I don’t recall seeing the Deadline 5 slave stalling like this, normally it was just max, or both, not just the slave. It sat there for quite a while with the rendering apparently at 100% and then timed-out.
Here the same, it grabs way to much ram, on nearly every node the same… I will open a support ticket an let you know when we find a solution on that.
Hey guys,
The Deadline 6 slave shouldn’t be using that much memory. When a slave gets up to using this much memory, can you guys grab the log for the slave on the machine and post it? If the launcher is running on the system, you can right-click on it to explore the log folder. Just grab the most recent slave log.
Also, can you guys check if your machines have all of their Windows updates applied?
Finally, do you typically only see this issue with Max jobs? Maybe it’s something specific to the max plugin.
We’ve logged this as an issue, and any additional information you can provide us will be very helpful.
Thanks!
How much RAM should the Deadlineslave.exe application use?
Our slaves, which have been running for days, are around 130 MB. That being said, another client of ours pointed out that their Slave was also at around 450 MB, and this slave was processing a 3dsmax job. Our plan is to run some tests with a bunch of max jobs to see if the memory climbs up over time, and then do the same with non-max jobs.
This job had no render elements but was very heavy data, used 30GB of Ram on a more powerful machine. The machine installs were pretty recent, new builds so should be up to date with all updates and most recent versions. We are rendering in 3dsmax 2013 and Vray 2.40.02 there was quite a lot of xref object entries and texture maps.
Another high memory job rendering 4k and the deadlineslave.exe is using 80mb of RAM… I will keep watching this to see when we next have RAM issues.
Sounds good. Keep us posted.
Having this problem again today, another very heavy job, we rendered it at the weekend and it was ok, today we’re getting trapped SEH problems, and I think it’s because DeadlineSlave.exe is eating all the RAM, going to do a machine restart on the farm and see if that fixes it temporarily.
Error being thrown…
“ERR: [V-Ray] UNHANDLED EXCEPTION: Compiling geometry Last marker is at ./src/vrenderlight.cpp, line 540: VRenderLightObj::update()”
I’ve sat here and watch the deadlineslave.exe RAM usage go from 600mb - 700mb and still climbing…
The task crashed out and the deadlineslave.exe was still using 700mb of RAM on the next task…
I’ve restarted the deadline slave, and now it’s using 80mb… but climbing during jobs again…
Restarted slave again, different job, still quite heavy but Deadlineslave only using 80mb RAM, confused…
Can you post the log from the slave from the session where it climbed up to 700 MB of ram? From the running slave, select Help -> Explore Log Folder, then sort by modified date/time to help find the correct log. I’m hoping that something in the log will indicate why the slave memory climbs like this. I’m guessing that it’s something to do with processing information being sent back to Deadline from 3dsmax (progress updates, etc), and that the slave is possibly falling behind when processing this information. That would explain the memory growth.
Here’s something else to try when the slave memory grows like that. Open the task manager, right-click on the deadlineslave.exe process, and select Create Dump File. In theory, this file should compress well, and then you can upload it for us to take a look at the memory footprint.
Thanks!
Here is a log sample, so things that seem odd,
2013-07-30 14:00:23: 0: STDOUT: QObject::moveToThread: Current thread (0x2d4b68b0) is not the object’s thread (0x2819c420).
We have a Postload script which takes a few minutes to run as it’s merging in some heavy data.
D
2013-07-30 13:57:05: Scheduler Thread - Successfully mapped X: to \bluearc.taylorjames.com\Data
We’ve just sent off the same file but with no pre-render script, just using XrefScene’s instead and there is no major memory leak, Deadlineslave.exe is around 100mb, and we have frames successfully rendering.
That’s interesting. Would you be able to share your pre-render script here or email it to us directly? Also, could you zip up and post that full slave log as an attachment? I’m more curious as to what the slave has been doing over time.
Can you Pm me your email address?
Dave_Wortley:
We’ve just sent off the same file but with no pre-render script, just using XrefScene’s instead and there is no major memory leak, Deadlineslave.exe is around 100mb, and we have frames successfully rendering.
I take that back, the tasks are now rendering but the deadlineslave.exe is slowly increasing in RAM usage, now up to 224mb
And now same blade it’s using just 32mb…
So it appears that the slave gets backed up (I’m guessing with socket communication with 3dsmax), but then can later recover. If this is the case, then it should be easier to track this down just within the scope of the 3dsmax plugin. We have this listed as a high priority bug to fix for 6.1.
Now I don’t know if this is something you’d be interested in doing, but it would be very helpful if it’s an option. You’re probably aware that we ship a 3dsCommand plugin with Deadline:thinkboxsoftware.com/deadline-6-3dscommand/
It would be interesting to see if you ever run into a memory problem using this plugin. It doesn’t have all the bells and whistles that the 3dsmax plugin does (which is why we’ll completely understand if you can’t use it to get your work done), but it would be a good test to see if the problem is specific to the 3dsmax plugin or not. If this is something you’d be willing to test out, we’d love to hear your feedback.
Cheers,
