[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] our ideal configuration
- Date: Fri, 29 Jun 2007 18:48:31 +0200
- From: Horvátth Szabolcs <szabolcs@xxxxxxxxxxxxx>
- Subject: Re: [Condor-users] our ideal configuration
Matt Hope wrote:
Yep, thats what I use but somehow its not as effective as it used to be.
Back in the 6.7.x days
when I set the rank of some jobs to a high value no low value job ever
started until the high ranked
jobs were serviced. I can't get the same behaviour with 6.8 and 6.9.
Might be an unintentional config change
This is pretty much like ours except if you want the user defined tags
you have to use startd RANK which triggers preemption. You can avoid
this if you are willing to use the retirement time to stop the
resulting preemptions actually causing vacations.
on my part, though...
I'm less interested in the attribute changes of running jobs, its the
idle ones that I care about.
Respecting attribute changes of running jobs is not supported at least
in 6.8 (see recent mail from me). If they are in the queue but not
running the changes will be respected.
Thats ok for us, the pool has very few submitters. And abusers are
killed on the spot. ;)
Note that mixing user priority and 'tagged' jobs requires some sense
on the part of the submitting user.
I thought that machine rank overrides user priorities altogether. Is it
If you submit jobs which are tagged high. let them start running then
submit a bunch of jobs on low but with much higher user priority then
the schedd will put these up for negotiation first. This can lead to
the high ones stopping (not sure if this will still happen - I gave up
looking into that a while back and just decided to try to keep
everything stable on our farm so such things didn't happen)
I have such a setup running (mostly based on those posts) but it stopped
If you search the list archives for 'TIER' and RANK you will find
several very useful threads that show you how to achieve what we
setup, later ones will include use of retirement to totally prevent
preemption due to the RANK)
It still takes machine rank into account but has much less effect.
We don't do DAGS - solves that one :)
Ok, I'll pass that on to my colleagues. ;) We only use DAGs...
Thats the only solution that I came up with but I don't like the fact
that job priority is replaced by dagmanjobid
using some stellar numbers. I can divide it of course but it still feels
a bit hacky approach.
That said there were some notes about using the recently added dag id
and the expansion of the range of the user specified priority to order
them appropriately, it may not play nice with Tiers with out some
thought on syncing their ordering