2014-03-03 23:46 GMT+01:00 Christopher Samuel <[email protected]>:
> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/03/14 04:53, Lyn Gerner wrote: > > > Have you also set AccountingStorageEnforce appropriately, as > > described here: http://slurm.schedmd.com/resource_limits.html ? > > We've had the association one from the start (we rely on hard limits > for CPU time for projects - i.e. accounts) so my first go with > association based limits should have worked. > > However, I didn't when I sent that email for the QoS based limits > though I fixed it shortly afterwards. > > I have a suspicion though that in the short window between me sending > that email and adding qos as an enforcement a number of the problem > users jobs finished, taking them below the 192 job cut off. :-/ > > My next task is to figure out how to implement the equivalent of > Maui/Moab's MAXIJOB such that any more than (say) 5 waiting jobs of a > user get marked as QOSResourceLimit, and then patch our local showq to > treat those as "blocked" and hide them from other users. > bf_max_job_user=# The maximum number of jobs per user to attempt backfill scheduling for, not counting jobs which cannot be started due to an association resource limit. One can set this limit to prevent users from flooding the backfill queue with jobs that cannot start and that prevent jobs from other users to start. This is similar to the MAXIJOB limit in Maui. The default value is 0, which means no limit. This option applies only to SchedulerType=sched/backfill. cheers, marcin
