<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Hi Folks,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">I've got a medium size cluster running slurm 20.11.8 with a bunch of QoS, Accounts and partitions configured and 3 tiers of priority which "float" over the nodes which are also assigned to the lower tiers rather than having specific nodes assigned to them. </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">The cluster wide preempt settings are:</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">PreemptMode             = CANCEL<br>PreemptType             = preempt/qos</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">I've also configured the weight of the qos to be the highest value factor when determining what is preempted. Here are the priority settings:</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">PriorityParameters      = (null)<br>PrioritySiteFactorParameters = (null)<br>PrioritySiteFactorPlugin = (null)<br>PriorityDecayHalfLife   = 7-00:00:00<br>PriorityCalcPeriod      = 00:05:00<br>PriorityFavorSmall      = No<br>PriorityFlags           = CALCULATE_RUNNING,NO_NORMAL_ALL<br>PriorityMaxAge          = 7-00:00:00<br>PriorityUsageResetPeriod = NONE<br>PriorityType            = priority/multifactor<br>PriorityWeightAge       = 10000<br>PriorityWeightAssoc     = 0<br>PriorityWeightFairShare = 0<br>PriorityWeightJobSize   = 1000<br>PriorityWeightPartition = 10000<br>PriorityWeightQOS       = 1000000<br>PriorityWeightTRES      = (null)<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">These 3 QoS tiers (which each have an associated account and partition) are: <br>1. windfall (no limits on nodes or jobs) which is preempted by the <br>2. cpuq and gpuq (limit 16 jobs/16 nodes per user per queue) which is preempted by <br>3. 16 group-specific queues with custom limits (between 4-12 nodes per group) which float either over the cpuq or gpuq and should instantly preempt jobs on both windfall and cpuq/gpuq</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Before we moved off select/linear the preemption was behaving as expected: when a higher priority job on a higher QoS tier would be submitted it would cancel the lower priority jobs as required and start running right away. However, when I moved the cluster to using select/cons_res about a year ago to enable users to run array jobs more effectively and to make the cluster utilization more efficient we started seeing some different behavior where higher priority jobs get "stranded" while awaiting resources.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">As an example we have recently seen full node jobs come in on the highest priority partitions and they don't immediately preempt the jobs on the cpuq or gpuq despite having much higher priority. Rather these high-priority jobs enter a state of "resources" (or "priority") and sit in the queue. These high priority jobs are within the resource limits of the partition and the qos so should not be held up by design. </div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Can anyone explain what is going on here? One thing I have  noticed is that the jobs which are running on the lower priority partition are usually NOT using all the resources of the nodes to which they are assigned. In other words those nodes show up as "mixed" rather than "allocated" in sinfo.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">For instance, the last time this occurred there were 16 preemptable gpuq jobs that were each running 1 to a node using 24 cores and all the RAM. The system owner requested that this specific queue comp-astro be set to user-exclusive (since their jobs are typically requiring full throughput of the filesystem), and not sure how that factors in here. However, these higher priority jobs did not kick the lower priority gpuq jobs out. Here is an example of the lower priority sprio output of one of the lower priority jobs</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">  JOBID PARTITION   PRIORITY       SITE        AGE    JOBSIZE  PARTITION        QOS<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">  171411 gpuq        20010017          0         10          7      10000   20000000<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">and here for the higer priority job</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">  JOBID PARTITION   PRIORITY       SITE        AGE    JOBSIZE  PARTITION        QOS<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">171441 comp-astr 1000010011          0          2          9      10000 1000000000<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">What I am trying to understand is why this lead to a state like this in squeue</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Here is squeue:<br>$ squeue<br>             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)<br>            171442 comp-astr  jid1    user PD       0:00      1 (Priority)<br>            171443 comp-astr  jid2    user PD       0:00      1 (Priority)<br>            171444 comp-astr  jid3    user PD       0:00      1 (Priority)<br>            171445 comp-astr  jid4    user PD       0:00      1 (Priority)<br>            171446 comp-astr  jid5    user PD       0:00      1 (Priority)<br>            171447 comp-astr  jid6    user PD       0:00      1 (Priority)<br>            171441 comp-astr  jid7    user PD       0:00      1 (Resources)<br></div><div>            171418      gpuq     <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jig1</span>   <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">user2</span>  R       7:23      1 gpu010<br>            171417      gpuq     <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jig2</span>   j<span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">user2</span><span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"></span>  R       7:33      1 gpu002<br>            171416      gpuq     <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jig3</span>   <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">user2</span><span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"></span><span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"></span><span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"></span>  R       7:46      1 gpu021<br>            171415      gpuq     <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jig4</span>   <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">user2</span>  R       7:47      1 gpu012<br>            171414      gpuq     <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jig5</span>   <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">user2</span>  R       7:50      1 gpu019<br>            171413      gpuq     <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jig6</span>   <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">user2</span>  R       7:54      1 gpu025<br>            171412      gpuq     <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jig7</span>   <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">user2</span>  R       8:27      1 gpu027<br>            171411      gpuq     <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">jig8</span>   <span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">user2</span>  R       8:28      1 gpu009<br></div><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">If it is indeed because of the open resources on the node that causes the preemption to not take place is there a way we can force the jobs on the gpuq to use all the resources so that it will work as expected? Do we need to have gpuq use --exclusive so that its jobs will always be cancelled?</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Thanks for your time,</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Josh</div><br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font face="verdana, sans-serif"><b>Josh Sonstroem</b></font><div><font face="verdana, sans-serif"><i>Sr. Platform Engineer</i></font></div><div><font face="verdana, sans-serif" size="1">Comm 33 / Information Technology Services<br></font></div><div><font face="verdana, sans-serif" size="1">cell (831) 332-0096</font></div><div><font face="verdana, sans-serif" size="1">desk (831) 459-1526</font></div><div><br></div></div></div></div></div></div>