[GE users] contemporary of -l slots=#

Raphael Y. Rubin rafi at cs.caltech.edu
Wed Mar 30 20:00:02 BST 2005

I would like to configure my grid so that mortal users can grab exclusive access to a machine, using the normal submittion commands with little extra work.

Occassionally, a user wants to run a job exclusively for benchmarking, whether that's to test a class of machine or a specific job.

Also some jobs we know will be resource hogs, and we'd like to annotate them to indicate they are the equivalent of two or more normal jobs.

And of course there are various other nees that arrise, but the above two are the most common and important.  In the past we just use to specify "-l slots=n".  But as of sge5.3 that was discouraged.

	error: denied: use parallel environments instead of requesting slots explicitly
		- from sge6

In sge 5.3, I had created a slots pe, after we first noticed the messages 
about -l slots.  Here is an updated version of that pe (in a form for sge 

pe_name           slots
slots             999
user_lists        NONE
xuser_lists       NONE
start_proc_args   /bin/true
stop_proc_args    /bin/true
allocation_rule   $pe_slots
control_slaves    FALSE
job_is_first_task TRUE
urgency_slots     min

Alternatively, one can use a consumable complex, as described  in:

or more simply:
#name               shortcut   type        relop requestable consumable 
default  urgency
vslots              vs         INT         <=    YES         YES        1 1000

Which is of course just the normal complex slots copied to a different 
name to get around the explicit "-l slots" block.  Somehow this seems 
wrong, a reincarnation of a technique deliberately killed for some reason 
unknown to me.

Which style is prefered and why?
What are the ramifications?
Are there any behavioral differences?

As for the prefered option, any suggestions to improve the above configurations?
Also what's the best way to deploy, either globally, or to a set of queues?

I know with sge 5.3, I was able to use:
queue_list        all
To deploy to my whole cell.

Also on a not complete tangent.  Does anyone have advice, or has anyone 
written guidelines to optimize configuration of queues?  We are mostly 
using dual cpu xeons with hyperthreading and 4G of ram.

Our jobs are mostly java, c, and lisp, single threaded (except the jvm 
which forks its own stuff).  Jobs mostly run in a few hundred MB or less, 
with a occasional memory hog which will eat a gig or two.

Rafi Rubin
California Institute of Technology

To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list