I’ve had a slave running (in nogui mode) for just under 2 days and it’s now reporting a memory load of 2.74 GB for the slave process itself (not the render process - lwsn). What’s going on? I’m not sure how to extract more information to help with this.
Odd. It sounds like a leak, but that’s quite the jump for only 2 days of running. During the beta, we had our OSX slave running for days while rendering thousands of tasks and its memory was stable. Those were Nuke jobs we were testing, so I wonder if it might be specific to the Lightwave plugin. Were your other nodes doing the same amount of work over that time span? What was their memory like?
I thought DL had Mono included with 5.1, so wasn’t sure it would make a difference. I can give it a try. However, looking at this again after I restarted that one node yields rather more information. Since this morning it’s gone from approx 270 MB RAM to 680 MB RAM. Even the 270 MB RAM made me quite surprised - that’s a fairly hefty baseline… On the other nodes, the slave is around 45-70 MB. Puzzling.
It seems to be an isolated, if unfortunate, case. They are all running the very same OS and external Mono configuration, so it’s very strange.
Deadline 5.1 still doesn’t ship with Mono. We originally wanted to look at this for 5.1, but now our plan is to do it for 6.0 (assuming it’s possible).
That is very strange that one machine is acting up like this. Maybe try reinstalling Mono 2.10.6 (or upgrading to 2.10.8), and reinstalling Deadline. Or, you could try uninstalling Mono (mono-project.com/Mono:OSX#Un … n_Mac_OS_X) and then installing 2.6.7. It might not help, but it can’t hurt.
Sierra:MacOS phil$ ./DeadlineMonitor
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Gtk not found (missing LD_LIBRARY_PATH to libgtk-x11-2.0.so.0?), using built-in colorscheme
System.Net.Sockets.SocketOptionName 0x1b is not supported at IPv6 level
Deadline Monitor 5.1: GdipCreateFromXDrawable_linux (System.EntryPointNotFoundException)
at (wrapper managed-to-native) System.Drawing.GDIPlus:GdipCreateFromXDrawable_linux (intptr,intptr,intptr&)
at System.Drawing.Graphics.FromXDrawable (IntPtr drawable, IntPtr display) [0x00000] in <filename unknown>:0
at System.Drawing.Graphics.FromHwnd (IntPtr hwnd) [0x00000] in <filename unknown>:0
at System.Windows.Forms.XplatUIX11.GetAutoScaleSize (System.Drawing.Font font) [0x00000] in <filename unknown>:0
at System.Windows.Forms.XplatUI.GetAutoScaleSize (System.Drawing.Font font) [0x00000] in <filename unknown>:0
at System.Windows.Forms.Form.GetAutoScaleSize (System.Drawing.Font font) [0x00000] in <filename unknown>:0
at System.Windows.Forms.Form..ctor () [0x00000] in <filename unknown>:0
at FranticXForms.CustomControls.CustomForm..ctor () [0x00000] in <filename unknown>:0
at FranticXForms.Forms.SplashScreen..ctor (System.Drawing.Bitmap bitmap) [0x00000] in <filename unknown>:0
at (wrapper remoting-invoke-with-check) FranticXForms.Forms.SplashScreen:.ctor (System.Drawing.Bitmap)
at FranticXForms.Forms.SplashScreen.ShowAsynch (System.Drawing.Bitmap bitmap) [0x00000] in <filename unknown>:0
at DeadlineMonitor.DeadlineMonitorApp.Main (System.String[] args) [0x00000] in <filename unknown>:0
I’ve downgraded to 2.6.7 and will see if that improves the situation…
UPDATE, 10 hours later. The removal of Mono 2.10.* and the subsequent Mono 2.6.7 install doesn’t seem to have made much difference. The slave is taking 500 MB RAM on this machine. I reinstalled Deadline from scratch before either of these activities, without any luck.