[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] our ideal configuration

Matt Hope wrote:
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.
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
on my part, though...

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.
I'm less interested in the attribute changes of running jobs, its the idle ones that I care about.

Note that mixing user priority and 'tagged' jobs requires some sense
on the part of the submitting user.
Thats ok for us, the pool has very few submitters. And abusers are killed on the spot. ;)
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 thought that machine rank overrides user priorities altogether. Is it not true?
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)
I have such a setup running (mostly based on those posts) but it stopped working efficiently.
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...
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
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.