Here's a portion of slurm.conf: # SCHEDULING SchedulerType=sched/backfill SchedulerParameters=bf_continue,bf_window=10080,bf_resolution=600,bf_max_job_test=10000,bf_interval=30,bf_max_job_user=50 #SchedulerAuth= #SchedulerPort= #SchedulerRootFilter= ## SelectType=select/linear FastSchedule=0 PriorityType=priority/multifactor PriorityDecayHalfLife=7-0 PriorityUsageResetPeriod=MONTHLY #PriorityDecayHalfLife=14-0 #PriorityUsageResetPeriod=14-0 #PriorityWeightFairshare=100000 #PriorityWeightAge=1000 #PriorityWeightPartition=10000 #PriorityWeightJobSize=1000 #PriorityMaxAge=1-0 # PriorityWeightQOS = 100000 PriorityWeightFairShare = 1000 PriorityWeightAge = 10 PriorityWeightJobSize = 1 PriorityWeightPartition = 1 PriorityMaxAge=1-0
The particular job in question has 0 priority. On Sat, Oct 29, 2016 at 7:50 PM, Benjamin Redling < [email protected]> wrote: > Are you allowed and able to post the slurm.conf? What does sprio -o %Q -j > <JobID> say about that job? BR, Benjamin > > Am 29. Oktober 2016 20:56:18 MESZ, schrieb Vlad Firoiu <[email protected] > >: >> >> I'm trying to figure out why utilization is low on our university >> cluster. It appears that many cores are available, but a minimal resource >> 10 minute job has been waiting in queue for days. There happen to be some >> big high priority jobs at the front of the queue, and I've noticed that >> these are being constantly scheduled and unscheduled. Is this expected >> behavior? Might it be causing slurm to never reach lower priority jobs and >> consider them for scheduling/backfill? >> > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. >
