From: matx <matx@(email surpressed)>
Subject: RenderMan for Maya taking too many licenses
   Date: Tue, 16 Dec 2008 03:32:01 -0500
Msg# 1804
View Complete Thread (3 articles) | All Threads
Last Next 
Hi
We're seeing an odd issue with RenderMan for Maya taking too many licenses when we submit through RUSH. Even when specifying "-n 4" manually in the submit script, which normally works fine. These are 8-proc Xeon Xserves running Mac OS X Server 10.5.5, and Rush 102.42a9. This may not be a Rush problem, as it usually render fine. But we restarted the Pixar RenderMan for Maya license server (v.5.0.2) and it seemed to have no affect on licenses being taken in excess by the clients. A frame would be rendering, reporting in rush, then suddenly the frame failed, and the time in reported rush to have been taken was less than earlier reported, and then multiple licenses will have been checked out until no licenses remain... Sounds like the renderman license server is to blame, and Rush is only showing the symptom, but I'd thought I'd bouce off some peeps here. I'll be sure to post on Pixar's forums, as well.
Anyone using RfMv.2 with Maya 2008 in Mac OS X? Any ideas? Of course, we're up against a tight deadline... When are we not? 

:)

Mat X



   From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: RenderMan for Maya taking too many licenses
   Date: Tue, 16 Dec 2008 09:07:23 -0500
Msg# 1805
View Complete Thread (3 articles) | All Threads
Last Next 
matx wrote:
> We're seeing an odd issue with RenderMan for Maya taking too many 
> licenses when we submit through RUSH. Even when specifying "-n 4" 
> manually in the submit script, which normally works fine. 

	In the rush hosts file, do you have the CPUS column
	set to values >1?

	If so, rush will try to start up to that many instances
	of your render on the machine, unless your job is set
	to prevent that.

	When you submit the job with '-n 4', try submitting
	the job with 'Ram:' set to the amount of ram
	rush has been configured to think each machine has.

	For instance, if your nodes each have 4000 of ram
	(in the rush/etc/hosts file), then submit with
	"Ram: 4000" to ensure no more than one instance
	of that job is started on each machine, to prevent
	using more licenses than you have.

> restarted the Pixar RenderMan for Maya license server (v.5.0.2) and it 
> seemed to have no affect on licenses being taken in excess by the 
> clients.

	You can probably use the licensing tools to determine
	which machines have which licenses checked out, to see
	why there are so many licenses being used.

	Try telling rush to render one of your scenes on just
	one machine, and then query the renderman license server
	to see how many licenses it thinks that machine has checked
	out for rendering, and then look at how many processes
	are actually running on the machine (with ps(1) or TaskManager)

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)


   From: matx <matx@(email surpressed)>
Subject: Re: RenderMan for Maya taking too many licenses
   Date: Tue, 16 Dec 2008 12:57:39 -0500
Msg# 1807
View Complete Thread (3 articles) | All Threads
Last Next 
On 2008-12-16 06:07:23 -0800, Greg Ercolano <erco@(email surpressed)> said:


	For instance, if your nodes each have 4000 of ram
	(in the rush/etc/hosts file), then submit with
	"Ram: 4000" to ensure no more than one instance
	of that job is started on each machine, to prevent
	using more licenses than you have.



I'll try setting the RAM explicitly. Good idea, I haven't tried that.



	Try telling rush to render one of your scenes on just
	one machine, and then query the renderman license server
	to see how many licenses it thinks that machine has checked
	out for rendering, and then look at how many processes
	are actually running on the machine (with ps(1) or TaskManager)
I'm using the Pixar licensing tools to check how many licenses stations have, and they'll often take two or three licenses. I don't know if its because a frame is failing then checking out a new frame before it lets go (or doens't let go) of the previous license, or because the license server does not use 
a persistent connection to the client to determine license status.

More poking required.

Thanks.

-x