<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:"Consolas",serif;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:447315037;
        mso-list-template-ids:-2076794910;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level3
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level5
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level6
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level8
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level9
        {mso-level-start-at:0;
        mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Have you looked at the High Throughput Computing Administration Guide: <a href="https://slurm.schedmd.com/high_throughput.html">https://slurm.schedmd.com/high_throughput.html</a><o:p></o:p></p><p class=MsoNormal>In particular, for this problem may be to look at the SchedulerParameters. I believe that the scheduler defaults to be very conservative and will stop looking for jobs to run pretty quickly.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal><b><span style='color:#002060'>Mike Robbert<o:p></o:p></span></b></p><p class=MsoNormal><b><span style='color:#002060'>Cyberinfrastructure Specialist, Cyberinfrastructure and Advanced Research Computing<o:p></o:p></span></b></p><p class=MsoNormal><span style='color:#767171'>Information and Technology Solutions (ITS)<o:p></o:p></span></p><p class=MsoNormal><span style='color:#767171'>303-273-3786 | </span><a href="mailto:mrobbert@mines.edu"><span style='color:#0563C1'>mrobbert@mines.edu</span></a><span style='color:#767171'> </span><span style='font-size:12.0pt;color:#767171'> <o:p></o:p></span></p><p class=MsoNormal><img border=0 width=208 height=38 style='width:2.1666in;height:.3958in' id="Picture_x0020_1" src="cid:image001.png@01D86601.9A802740" alt="A close up of a sign Description automatically generated"><span style='font-size:12.0pt;color:#767171'><o:p></o:p></span></p><p class=MsoNormal><b><span style='color:#2B4160'>Our values:</span></b><span style='color:#2B4160'> </span><span style='color:#767171'>Trust | Integrity | Respect | Responsibility</span><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>slurm-users <slurm-users-bounces@lists.schedmd.com> on behalf of David Henkemeyer <david.henkemeyer@gmail.com><br><b>Date: </b>Thursday, May 12, 2022 at 12:34<br><b>To: </b>Slurm User Community List <slurm-users@lists.schedmd.com><br><b>Subject: </b>[External] Re: [slurm-users] Question about having 2 partitions that are mutually exclusive, but have unexpected interactions<o:p></o:p></span></p></div><div style='border:solid #9C6500 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FFEB9C'><b><span style='font-size:10.0pt;color:#9C6500'>CAUTION:</span></b><span style='font-size:10.0pt;color:black'> This email originated from outside of the Colorado School of Mines organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Thanks Brian.  We have it set to 100k, which has really improved our performance on the A partition.  We queue up 50k+ jobs nightly, and see really good node utilization, so deep jobs are being considered. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Could be that we have the scheduler too busy doing certain things, that it takes a while for it to figure out that the B jobs, despite being lower priority, can be run on partition B, with nothing higher priority targeted for that partition.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>My wish here would be to be able to tell the controller to spawn a separate thread, and have one thread focus only on the B partition, while the other focuses on the rest.  Or something similar.  <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>David<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, May 12, 2022 at 9:13 AM Brian Andrus <<a href="mailto:toomuchit@gmail.com">toomuchit@gmail.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p>I suspect you have too low of a setting for "MaxJobCount"<o:p></o:p></p><pre style='font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px'><b><span style='font-size:9.5pt;color:black'>MaxJobCount</span></b><span style='font-size:9.5pt;color:black'><o:p></o:p></span></pre><pre><span style='font-size:9.5pt;color:black'>              The maximum number of jobs SLURM can have in its active database<o:p></o:p></span></pre><pre><span style='font-size:9.5pt;color:black'>              at one time. Set the values  of  <b>MaxJobCount</b>  and  <b>MinJobAge</b>  to<o:p></o:p></span></pre><pre><span style='font-size:9.5pt;color:black'>              insure the slurmctld daemon does not exhaust its memory or other<o:p></o:p></span></pre><pre><span style='font-size:9.5pt;color:black'>              resources. Once  this  limit  is  reached,  requests  to  submit<o:p></o:p></span></pre><pre><span style='font-size:9.5pt;color:black'>              additional  jobs will fail. The default value is 5000 jobs. This<o:p></o:p></span></pre><pre><span style='font-size:9.5pt;color:black'>              value may not be reset via "scontrol reconfig".  It  only  takes<o:p></o:p></span></pre><pre><span style='font-size:9.5pt;color:black'>              effect  upon  restart  of  the slurmctld daemon.  May not exceed<o:p></o:p></span></pre><pre><span style='font-size:9.5pt;color:black'>              65533.<o:p></o:p></span></pre><p><o:p> </o:p></p><p>so if you already have (by default) 5000 jobs being considered, the remaining aren't even looked at.<o:p></o:p></p><p>Brian Andrus<o:p></o:p></p><div><p class=MsoNormal>On 5/12/2022 7:34 AM, David Henkemeyer wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>Question for the braintrust: <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I have 3 partitions:<o:p></o:p></p></div><div><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Partition A_highpri: 80 nodes<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Partition A_lowpri: same 80 nodes<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Partition B_lowpri: 10 different nodes<o:p></o:p></li></ul></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There is no overlap between A and B partitions.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Here is what I'm observing.  If I fill the queue with ~20-30k jobs for partition A_highpri, and several thousand to partition A_lowpri, then, a bit later, submit jobs to partition B_lowpri, I am observing that the Partition B jobs <u>are queued and not running right away, and are given a pending reason of "Priority"</u>, which doesn't seem right to me.  Yes, there are higher priority jobs pending in the queue (the jobs bound for A_hi), but there aren't any higher priority jobs pending <i>for the same partition</i> as the Partition B jobs, so theoretically, these partition B jobs should not be held up.  Eventually, the scheduler gets around to scheduling them, but it seems to take a while for the scheduler (which is probably pretty busy dealing with job starts, job stops, etc) to figure this out.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If I schedule fewer jobs to the A partitions ( ~3k jobs ), then the scheduler schedules the PartitionB jobs much faster, as expected.  As I increase from 3k, then partition B jobs get held up longer and longer.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I can raise the priority on partition B, and that does solve the problem, but I don't want those jobs to impact the partition A_lowpri jobs.  In fact, <u>I don't want any cross-partition influence</u>.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm hoping there is a slurm parameter I can tweak to make slurm recognize that these partition B jobs shouldn't ever have a pending state of "priority".  Or to treat these as 2 separate queues.  Or something like that.  Spinning up a 2nd slurm controller is not ideal for us (uless there is a lightweight method to do it).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks<o:p></o:p></p></div><div><p class=MsoNormal>David<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></blockquote></div></blockquote></div></div></div></body></html>