[gridengine users] control of queuing order

[Reuti]

Am 06.10.2011 um 14:46 schrieb Jesse Becker:

> 4) Similar to suggestion #2 (Functional/Sharetree), but use override
> tickets on per-{user,job,project,department}.

> On Thu, Oct 06, 2011 at 05:21:08AM -0400, Erik Soyez wrote:
>> Good day Rick,
>>
>> 3) urgency
>>
>> Add a requestable boolean ressource (e.g. prio) with high urgency
>> value, put it into your queue as "complex_value prio=True" and
>> your users can submit jobs with "qsub -l prio ....".  Also very
>> useful in combination with different queues, e.g. "high" and "low".
>>
>> Regards, Erik Soyez.
>>
>>
>> On Thu, 6 Oct 2011, Stephen Willey wrote:
>>
>>> As you say, you modify priority in GridEngine rather than order as
>> such.  We use (or are looking at using) a couple of methods to manage
>> the kind of ordering you're talking about:
>>
>> 1) POSIX Priority - We have 5 levels: Highest, High, Normal, Low,
>> Whenever which just map to 600,300,0,-300,-600 and then weight
>> Priority much higher than tickets.  If we have a super important job
>> and they're screaming it must run, I just bump the priority number to
>> 1000.
>> 2) Share tree/Functional.  We're looking to deploy a setup that  
>> looks like:
>> Project A - 80
>> Project B - 20
>> Company Priority - 1000000
>> When it's decided that something's a company priority, it's obviously
>> going to get pretty much all the tickest.

These are two things. So: 2a) fshare setting in the project/user/ 
department definition.

Share-tree: honors the past usage.

Functional: define relations for the various entries what should run  
right now in the cluster, ignoring past usage.

You could combine them though.


>> I guess you could just use POSIX priorities and turn weight all the
>> urgency/ticket stuff to 0.  Anything not set with a higher/lower
>> priority would just run FIFO (I haven't tried this and I might be
>> wrong)
>>
>> Stephen
>>
>> On Wed, Oct 5, 2011 at 7:42 PM, Rick Reynolds II
>> <Rick.ReynoldsII at ecitele.com> wrote:
>>> We're looking at using SGE to replace a home-grown queuing system  
>>> that is showing its age in terms of legacy maintenance, etc.
>>>
>>> The previous system was strictly FIFO for each queue.  You add a  
>>> job to a specific queue, and it waits its turn.  As I'm reading  
>>> more about SGE and the various policies that can be used to  
>>> control queuing, I'm getting the impression that real, hard  
>>> control of the order of jobs isn't something that SGE provides  
>>> when you're using the different policies to help it determine job  
>>> priorities.  Is that right?

Yes. I think it was Andy who phrased it once like being more like a  
steering wheel of a ship and you have to trust to go the right way  
overall (I don't remember the correct wording though).

-- Reuti


>>>
>>> We're interested in being able to classify certain jobs as higher  
>>> priority.  And I'd guess we'd specify policies to guide the ticket  
>>> allocation for those kinds of jobs.  But if I'm using those  
>>> policies will I still be able to specify something like "give this  
>>> specific job the next position in the queue"?
>>
>>
>> -- 
>>
>> -- 
>> Vorstand/Board of Management:
>> Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
>> Dr. Arno Steitz, Dr. Ingrid Zech
>> Vorsitzender des Aufsichtsrats/
>> Chairman of the Supervisory Board:
>> Philippe Miltin
>> Sitz/Registered Office: Tuebingen
>> Registergericht/Registration Court: Stuttgart
>> Registernummer/Commercial Register No.: HRB 382196
>>
>
>> _______________________________________________
>> users mailing list
>> users at gridengine.org
>> https://gridengine.org/mailman/listinfo/users
>
>
> -- 
> Jesse Becker
> NHGRI Linux support (Digicon Contractor)
> _______________________________________________
> users mailing list
> users at gridengine.org
> https://gridengine.org/mailman/listinfo/users
>