Hi, We have used priority/multifactor for our scheduling where members got higher "share" 3 vs 1 for guests. This priority setup for member does not seem to put their job priority higher compared to guests. At the same time, we have issues where jobs got stuck in the queue with (Priority) as the reason without us really understanding why the jobs would not run despite the available resources. As such, we are thinking of shifting back to priority/basic to remove the user dissatisfaction with the Priority reason. The question is how do we put higher priority for members in the priority/basic setup? A secondary question is whether we are doing the right member prioritization by using "share" only or should we adjust another parameter to help members get their job run earlier? Thanks, Hadrian
This falls outside of our "Level 3" support model; this is material that is covered as part of training, or that you're expected to find in the documentation. I will try to provide some quick pointers here, but am marking this closed. Please reopen if you have specific questions about issues you're facing or if you think there are mistakes with the documentation. - Tim > We have used priority/multifactor for our scheduling where members got > higher "share" 3 vs 1 for guests. This priority setup for member does not > seem to put their job priority higher compared to guests. At the same time, > we have issues where jobs got stuck in the queue with (Priority) as the > reason without us really understanding why the jobs would not run despite > the available resources. Both 'sshare' and 'sprio' should help explain the different priority structures. > As such, we are thinking of shifting back to priority/basic to remove the > user dissatisfaction with the Priority reason. priority/basic is almost never recommended; I believe you'll have much better results getting (a) the different multifactor weights established, and (b) a fairshare hierarchy reflecting your requirements. http://slurm.schedmd.com/priority_multifactor.html http://slurm.schedmd.com/fair_tree.html This a newer fairshare approach introduced in 15.08, but is the one we're usually recommending now, and includes an overview of how to model out your priorities which applies for normal fairshare or the new fairtree: http://slurm.schedmd.com/SUG14/fair_tree.pdf If you want to explicitly establish two service classes and don't care to setup multifactor, you can simply create two overlapping partitions, one with a higher priority. Anything in the higher priority partition would block all jobs in lower priority partitions from launching. > The question is how do we put higher priority for members in the > priority/basic setup? A secondary question is whether we are doing the right > member prioritization by using "share" only or should we adjust another > parameter to help members get their job run earlier? You can't. priority/basic doesn't do anything to affect job priorities, it's effectively a FIFO queue.
