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
<[email protected]> 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
[email protected]
https://gridengine.org/mailman/listinfo/users
--
Jesse Becker
NHGRI Linux support (Digicon Contractor)
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
