On Tue, 7 Feb 2012 19:59:22 +0100 "Yuri D'Elia" <wav...@thregr.org> wrote:
> [2012-02-07T19:39:33] Normalized usage for account default off root > 5747776.753815 / 5747776.753815 = 1.000000 > [2012-02-07T19:39:33] Effective usage for account default off root 1.000000 > 1.000000 > [2012-02-07T19:39:33] Decay factor over 300 seconds goes from > 0.999998854166667 -> 0.999656308878391 > [2012-02-07T19:39:34] job 460729 ran for 300 seconds on 1 cpus > [2012-02-07T19:39:34] grp_used_cpu_run_secs is 0, will subtract 0 > [2012-02-07T19:39:34] grp_used_cpu_run_secs is 0, will subtract 0 > .... > (followed by what looks like a priority decay run). > > It seems that 465060 is the first submitted job (in a row of submissions) > where priority has not been calculated. It's immediately followed by a decay > run. The jobs before/after this job just contain the following: It seems that every time "PriorityCalcPeriod" is run, some jobs (usually the newer ones, beyond some sort of threshold) loose their "association" with priorities. I wonder if backfilling limits has anything to do with that? I set the following: PriorityCalcPeriod=99-00:00:00 PriorityDecayHalfLife=0 PriorityUsageResetPeriod=DAILY and now I can submit oodles of jobs without jobs dropping their priorities (until I reach the 99 days mark I guess). But of course, now the AGE/FAIRSHARE factor is never recalculated for queued jobs.
