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

Re: [Condor-users] condor 6.7.6 load limit?

On Mon, 5 Sep 2005, Matt Hope wrote:

On 9/1/05, Jeffrey McDonald <jeffrey.mcdonald@xxxxxxxxxxx> wrote:
However, one problem that remains is that none of the condor submitted
jobs generate a load of more than 30% on the CPU that it is running on.
This is regardless of whether the machine has interactive activity or
not.    The net result is that jobs that take 20 minutes to run at a
high priority take 4-5 hours.

condor has nothing to do with this (assuming your machines have no other significant tasks running on them in which case forcing the processes to a higher priority could help)

I beg to differ. By default, under Linux, Condor will set the scheduling priority of the jobs it runs to 10. Under most normal circumstances, the "default" scheduling priority of a job run "by hand" whilst logged into a machine would be 0 (unless the machine has been specially configured otherwise), and this could make a considerable difference.

In fact, if the jobs are being running at a high scheduling priority (i.e less than 0), then if Condor runs the jobs at the fairly low scheduling priority of 10, the difference in run time could be *huge*.

One can change the scheduling priority with which Condor runs a job (to a value in the range 0 to 19) by setting the JOB_RENICE_INCREMENT in the condor_config file, see (for Condor 6.7.6):


Note that Condor won't set the scheduling priority to anything lower than 0 - if you set JOB_RENICE_INCREMENT to a value lower than 0, then it will behave as though you'd set it to 0. (This means that if you were running your jobs at a high scheduling priority (i.e. less than 0), then you're unlikely to get comparable performance by running them under Condor, I'm afraid. Perhaps the Condor team might wish to consider allowing Condor to run jobs under UNIX/Linux at any scheduling priority in the range -20 to 20 in future releases...)

Jeff: hope that helps!,

	-- Bruce

Bruce Beckles,
e-Science Specialist,
University of Cambridge Computing Service.