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

Re: [Condor-users] our ideal configuration

On 6/29/07, Horvátth Szabolcs <szabolcs@xxxxxxxxxxxxx> wrote:

I was trying to find the ideal configuration settings for our needs and
although part of it works nicely I still could not
get everyting working as intended. Any tip, example or experience with
similar setups is much appreciated!

- No preemtion.

- The job execution order should be controlled by custom job attributes
(low/mid/high priority) and the execution
order should respect both this setting and condor job priority. User
priority should balance job count between
users but an important task should run in spite of user priority.
Important stuff should be out the door as fast as it can be
without preemption.

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.

- Job execution should be as much first-in-first-out as can be but it
should respect attribute changes of the users.

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.

Note that mixing user priority and 'tagged' jobs requires some sense
on the part of the submitting user.

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)

Our config is very tuned to our internal setup (in terms of using the
arbitrary slot 1 and 2 distinction to split the farm somewhat) so
wouldn't make a good template.
Ian Chesal also did similar things to this, And I borrowed some ideas
from him.

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)

- DAGs of a user should run one after the other: by default if maxidle
or maxjobs flags are used and more dags
are submitted than the execution of jobs gets mingled between DAGs, they
run in the order of job submission.
I'd like to have the first submitted dag complete and only then start
the jobs of the next one.

We don't do DAGS - solves that one :)
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

Sounds like simple stuff to get working but... :)

Apart from the DAGS it is (the retirement bit is a little complex to
start with as it requires some changes on both submission and
execution config but is easy to test).