<div dir="auto">This is intentional behaviour so that the maximum resources are kept free, in case a large job of some kind is queued.<div dir="auto"><br></div><div dir="auto">In principle each job on the first node is guaranteed the CPUs and memory required, so they don't compete...much. The reality is that this is very much affected by resources that cannot be exclusive such as IO to storage.</div><div dir="auto"><br></div><div dir="auto">We have used the --spread-jobs option with some success but I think it spreads the jobs of a single sbatch file rather than cause a new job to scale horizontally. </div><div dir="auto"><br></div><div dir="auto">I'm sure others know better.<br><br><div data-smartmail="gmail_signature" dir="auto">William Brown</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 Aug 2022, 18:31 Alejandro Acuña, <<a href="mailto:alejandro.acunia@iflp.unlp.edu.ar">alejandro.acunia@iflp.unlp.edu.ar</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all.<br>
Under Slurm 19.05, is there a way to configure partition nodes to submit batch jobs indicating partition only? But...important detail: these job must start in node that is having less work of the partition.<br>
I hope you understand my drama. Under same partition, actually jobs run fine, but they accumulate in the first node and only new jobs use the second one when resources are not enough. Ideally, a job would start on a node with no job (in case there is).<br>
For the record: the only command I found and perform similar is: <br>
salloc --exclusive [file to submit]<br>
Whit salloc, if user submit same file many times, jobs are distributed in each node of the partition. But, this is not under batch plane.<br>
<br>
Thanks<br>
Ale<br>
<br>
</blockquote></div>