[GE users] queue priorities?

Chris Dagdigian dag at sonsorol.org
Wed Jul 14 22:46:15 BST 2004

Hi Don,

{my $.02}

The concept of queues with high/normal/low priority is something that 
people traditionally familiar with PBS and Platform LSF try to 
transplant directly into Grid Engine deployment configuration.

Much of the confusion when this happens is due to the fact that the 
concept of a queue in Grid Engine is quite different from a 'queue' in 

As a general thing with SGE you don't really want your cluster users to 
be thinking about queues at all (as someone with lots of LSF background 
this was hard for me to deal with at first...) SGE queues are just 
containers for running jobs on an execution host, they are not pending 
bins for jobs sorted on priority etc.

In the SGE model all the user should do is describe the resources 
necessary for successful job completion. The SGE scheduler and qmaster 
then handle the task of picking the best available queue instance to run 
the job on within the context of the various resource allocation 
policies and configuration settings that are in effect.

The decision regarding when jobs run and what user/department/project 
gets what percentage of available resources is based on scheduling 
policies, not the name of the queue they submitted the job to.

Generally speaking it is possible to do what you want but often the 
cleaner and more powerful/flexible approach over time is to 'go with the 
flow' by understanding how the policy mechanisms work within Grid Engine.

Once you can describe how you want your business or scientific goals to 
be expressed dynamically in cluster resource allocation you can more 
easily configure the SGE to suit your needs.

I can't give you any specific config pointers without knowing more 
details about how you want to allocate resources.

For instance there is a simple priority mechanism within the standard 
SGE 5.3 product that lets users describe the relative priority of their 
jobs (I think via the '-p' qsub argument). This may or may not be 
suitable for you because the entire concept hinges upon trusting the 
users to self-police themselves. This works for some people and not at 
all for others :)

Another approach that is similar to what you are describing as your need 
involves the concept of Subordinate queues (which are well covered in 
the SGE documentation). You can configure "high" "medium" and "low" 
queues on each host and make them subordinate to each other. When the 
"high" queue is fully engaged the other queues can be configured such 
that they become disabled or suspended. Again, I'm not sure if this is 
suitable for your needs or not since I don't know if you are "trusting" 
the users to pick a queue or if you want everything handled behind the 
scenes by SGE and the SGE administrator account.

SGE 5.3 Enterprise Edition has functional and share tree policies which 
are great for allocating resources based on user, group, department or 

If your need for high/low/medium priority queues is really due to the 
fact that some users/groups/projects/departments are more "important" 
than others then the SGE Functional and Share Tree policies would 
probably work great.

SGE 6.0 has the 5.3 Enterprise Edition functionality with some 
additional scheduling and policy improvements as well.


Don Shesnicky wrote:

>>To suspend them, you can use the subordinate queue feature (man
> queue_conf ).
> Reuti,
> Can you give me some more details on how to do the priority setting? I'm
> having 
> some trouble getting my head around how to configure sge. It seems a bit
> obtuse.
> Basically I want a high, normal and low priority set of queues where
> jobs in the 
> high get either more cycles then the others or totally suspend jobs in
> the others. 
> Sounds pretty simple but the technique just doesn't seem obvious.
> Don

Chris Dagdigian, <dag at sonsorol.org>
BioTeam  - Independent life science IT & informatics consulting
Office: 617-665-6088, Mobile: 617-877-5498, Fax: 425-699-0193
PGP KeyID: 83D4310E iChat/AIM: bioteamdag  Web: http://bioteam.net

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