<div dir="ltr"><div><div>"Otherwise a user can have a sing le job that takes the entire cluster,  and insidesplit it up the way he wants to."<br></div>Yair, I agree. That is what I was referring to regardign interactive jobs. Perhaps not a user reserving the entire cluster,<br></div>but a use reserving a lot of compute nodes and not making sure they are utilised fully.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 May 2018 at 09:37, Yair Yarom <span dir="ltr"><<a href="mailto:irush@cs.huji.ac.il" target="_blank">irush@cs.huji.ac.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
This is what we did, not sure those are the best solutions :)<br>
<br>
## Queue stuffing<br>
<br>
We have set PriorityWeightAge several magnitudes lower than<br>
PriorityWeightFairshare, and we also have PriorityMaxAge set to cap of<br>
older jobs. As I see it, the fairshare is far more important than age.<br>
<br>
Besides the MaxJobs that was suggested, we are considering setting up<br>
maximum allowed TRES resources, and not number of jobs. Otherwise a<br>
user can have a single job that takes the entire cluster, and inside<br>
split it up the way he wants to. As mentioned earlier, It will create<br>
an issue where jobs are pending and there are idle resources, but for<br>
that we have a special preempt-able "requeue" account/qos which users<br>
can use but the jobs there will be killed when "real" jobs arrive.<br>
<br>
## Interactive job availability<br>
<br>
We have two partitions: short and long. They are indeed fixed where<br>
the short is on 100% of the cluster and the long is about 50%-80% of<br>
the cluster (depending on the cluster).<br>
<br>
</blockquote></div><br></div>