<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hi</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">We've run into similar problems with backfill (though not apparently of the scale you've got).  We have a number of users who will drop 5,000+ jobs at once- as you've indicated, this can play havoc with backfill.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">One of the newer* parameters for the backfill scheduler that's been a real help for us is "bf_max_job_assoc" and "bf_max_job_user".  These limit the number of jobs the scheduler considers per association and user. </div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default"><font face="monospace">SchedulerParameters=bf_continue,bf_interval=120,bf_job_part_count_reserve=6,bf_window=43200,bf_resolution=1800,bf_max_job_user=200,bf_max_job_assoc=200,bf_max_job_part=500,bf_max_job_test=2000,bf_yield_interval=1000000,default_queue_depth=500,defer,partition_job_depth=300,max_rpc_cnt=200,preempt_youngest_first</font><br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">- Michael</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">*I think these are newer- I don't actually know when those were added (I'm currently on 17.11.5)</div><input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"7","compose-window":{"secure":false}}"></div></div></div><br><div class="gmail_quote" style=""><div dir="ltr">On Wed, Oct 10, 2018 at 6:08 PM Richard Feltstykket <<a href="mailto:rafeltstykket@ucdavis.edu">rafeltstykket@ucdavis.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello list,<br>
<br>
My cluster usually has a pretty heterogenous job load and spends a lot of the time memory bound.  Ocassionally I have users that submit 100k+ short, low resource jobs.  Despite having several thousand free cores and enough RAM to run the jobs, the backfill scheduler would never backfill them.  It turns out that there were a number of factors: They were deep down in the queue, from an account with low priority, and there were a lot of them for the scheduler to consider.  After a bunch of tuning, the backfill scheduler parameters I finally settled on are:<br>
<br>
SchedulerParameters=defer,bf_continue,bf_interval=20,bf_resolution=600,bf_yield_interval=1000000,sched_min_interval=2000000,bf_max_time=600,bf_max_job_test=1000000<br>
<br>
After implementing these changes the backfill scheduler began to successfully schedule these jobs on the cluster.  While the cluster has a deep queue, the load on the slurmctld host can get pretty high.  However no users have reported issues with responsivenes of the various slurm commands and the backup controller has never taken over either.  Changes have been in place for a month or so with no ill effects that I have observed.<br>
<br>
While I was troubleshooting I was definitely combing the list archives for other people's tuning suggestions, so I figured I would post a message here for posterity as well as see if anyone has similiar settings or feedback :-).<br>
<br>
Cheers,<br>
Richard<br>
</blockquote></div></div>