Administering Platform LSF - SAS

Using Historical and Committed Run Time
230
Using Historical and Committed Run Time
Historical run time decay
Configuring
Administering Platform LSF
By default, as a job is running, the dynamic priority decreases gradually until
the job has finished running, then increases immediately when the job finishes.
In some cases this can interfere with fairshare scheduling if two users who
have the same priority and the same number of shares submit jobs at the same
time.
To avoid these problems, you can modify the dynamic priority calculation by
using either or both of the following weighting factors:
◆ Historical run time decay
◆ Committed run time
By default, historical run time does not affect the dynamic priority. You can
configure LSF so that the user’s dynamic priority increases gradually after a
job finishes. After a job is finished, its run time is saved as the historical run
time of the job and the value can be used in calculating the dynamic priority,
the same way LSF considers historical CPU time in calculating priority. LSF
applies a decaying algorithm to the historical run time to gradually increase the
dynamic priority over time after a job finishes.
Specify ENABLE_HST_RUN_TIME=Y in lsb.params. Historical run time is
added to the calculation of the dynamic priority so that the formula becomes
the following:
dynamic priority = number_shares / (cpu_time * CPU_TIME_FACTOR +
(historical_run_time + run_time) * RUN_TIME_FACTOR + (1 + job_slots) *
RUN_JOB_FACTOR)
◆ historical_run_time
The historical run time (measured in hours) of finished jobs accumulated
in the user’s share account file. LSF calculates the historical run time using
the actual run time of finished jobs and a decay factor such that 1 hour of
recently-used run time decays to 0.1 hours after an interval of time
specified by HIST_HOURS in lsb.params (5 hours by default).
How mbatchd reconfiguration and restart affects historical run time
After restarting or reconfiguring mbatchd, the historical run time of finished
jobs might be different, since it includes jobs that may have been cleaned from
mbatchd before the restart. mbatchd restart only reads recently finished jobs
from lsb.events, according to the value of CLEAN_PERIOD in lsb.params.
Any jobs cleaned before restart are lost and are not included in the new
calculation of the dynamic priority.
Example
The following fairshare parameters are configured in lsb.params:
CPU_TIME_FACTOR = 0
RUN_JOB_FACTOR = 0
RUN_TIME_FACTOR = 1
Note that in this configuration, only run time is considered in the calculation
of dynamic priority. This simplifies the formula to the following: