[GE users] queue priorities?

Stephan Grell stephan.grell at sun.com
Fri Jul 16 08:39:04 BST 2004


Don Shesnicky wrote:

> 
>
>Stephan,
>I had a queue structure as you mentioned below, where there is a
>high, normal and low with subordinate lists as you mention where
>the high suspends the normal and low and the normal the low. What
>I don't understand is the complexes and what they add to the setup.
>Could you explain that?
>  
>
They ensure, that only jobs which request the resources will get into 
the according
queues. If you do not have the resources a low priority job might run in 
a medium or
high priority queue.

Without the resources, one could do:

qsub ... -q "medium.q" -> will run in a medium queue
qsub ... -q "high.q" -> will run in a high queue
qsub .... -> will run in any queue

with the resources ->

qsub .... -> will run in the low priority queue
qsub .... -q "high.q" -> will not run, because it is not requesting "-l 
high"
qsub ... -l medium -> will run in a medium queue

Another advantage of the resource is the use of them for the job 
priority computation.
Using the urgency policy you can ensure, that high priority jobs get a 
higher priority
than low priority jobs. Which will ensure a faster dispatching from the 
scheduler.

And there is a down side of this setup:

Assuming that a low priority job consums "license=1". The low priority 
job gets the
last available license in the system, than a high priority job with the 
same license
request cannot start until the low priority job has finished. Having the 
urgency
policy in place ensures, that the scheduler always works on the high 
priority jobs
first.
This is off course not helping, when a new high priority job enters the 
systems and a
low priority job is already working with the license. But it will 
prevent other pending
low-priority jobs from taken the license away from the high priority job.

Well, you can also use other policies for distinguishing between high 
and low priority
jobs. But I thought that this one would be the easiest.

I hope it helps,
Stephan

>Don
>
>-----Original Message-----
>From: Stephan Grell - Sun Germany - SSG - Software Engineer
>[mailto:stephan.grell at sun.com] 
>Sent: Thursday, July 15, 2004 3:27 AM
>To: users at gridengine.sunsource.net
>Subject: Re: [GE users] queue priorities?
>
>Hi Don,
>
>the setup you want is possible. I will write down an example and hope
>that it helps:
>
>two complexes (qconf -mc):
>medium medium bool == forced yes 0 1
>high       high      bool == forced yes 0 2
>
>three queues:
>
>all.q (keeps the defaults)
>
>medium.q (qconf -aq medium.q) - change:
>  complex_values     medium=true
>  subordinate_list      all.q=1
>
>high.q (qconf -aq high.q) - change:
>  complex-values     high=true
>  subordinate_list      all.q=1, medium.q=1
>
>
>In a setup like this, a job has to request the medium or high resource
>to get in one of those queues, otherwise it will run in the all.q. If a
>job starts in medium.q, the jobs in the all.q will be suspended and
>resumed, when the job in the medium queue has finished. The same is true
>for the high.q, exept, that the jobs i the medium.q will be suspended as
>well.
>To ensure not too many job suspensions, you can use the urgency policy
>to give jobs, which request medium/high a higher scheduling priority
>that others.
>
>
>Does this help?
>
>Cheers,
>Stephan
>
>
>Chris Dagdigian wrote:
>
>  
>
>>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
>>    
>>
>
>  
>
>>LSF or PBS.
>>
>>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 project.
>>
>>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.
>>
>>-Chris
>>
>>
>>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
>>>
>>>      
>>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>For additional commands, e-mail: users-help at gridengine.sunsource.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