<br><div class="gmail_quote">On Sat, Oct 1, 2011 at 1:57 PM,  <span dir="ltr">&lt;Gareth.Williams@csiro.au&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">&gt; -----Original Message-----<br>
&gt; From: Arnau Bria [mailto:<a href="mailto:arnaubria@pic.es">arnaubria@pic.es</a>]<br>
</div><div class="im">&gt; Sent: Friday, 30 September 2011 8:23 AM<br>
&gt; To: <a href="mailto:mauiusers@supercluster.org">mauiusers@supercluster.org</a><br>
&gt; Subject: Re: [Mauiusers] maui limits? looking for experience<br>
&gt;<br>
</div><div><div></div><div class="h5">&gt; On Fri, 30 Sep 2011 07:23:52 +1000<br>
&gt; Gareth.Williams@csiro.au Gareth.Williams@csiro.au wrote:<br>
&gt;<br><br>
</div></div>Hi Arnau,<br></blockquote><div><br>Hi Gareth,<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I have to guess more than I&#39;d like to in order to answer. However, it might be good to start by noting that the question presumes that maui starts many jobs in one cycle. I think this is rare (but have no idea what the limit is if there is one).  Most commonly, one might hope the cluster is busy so maui can only start a small number of jobs when other jobs finish. Jobs with highest priority reserve resources in the future to ensure they get started, other jobs may get backfilled. Only jobs that fit within the idle limits will be considered (for which they must be in an execution queue too).<br>
</blockquote><div><br>Ideally it should start few jobs, but due to our &quot;big&quot; schedulling cycle (we need it because when maui schedules it does not respond to user commands) and the fact that maui stops schedulling jobs when it finds a &quot;new&quot; node busy (is a &quot;bug&quot; we are seeing since we increased our farm size, already reported here, maybe I should open a bug) some cycles could start more than 200 jobs. As the ideal IDLE limit should be around 100 jobs per user, we&#39;ll be facing the issue previosuly described.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If the cluster is relatively idle, then it will probably fill up with work from whoever queues it first.<br>
<br>
If you have target shares, you can only meet them with a relatively consistent balance if all the shareholders submit plenty of jobs that don&#39;t have very different requirements.  Otherwise you need to be content with reasonable balance over the long term and fair-share scheduling helping the priority to slosh back and forth usefully.<br>
</blockquote><div><br>Our case is the first you describe, and, after some test, we&#39;ve met a good FS configuration and we&#39;re quite happy with FS targets.But as we have many users/groups we need a &quot;long&quot; IDLE queue in order to have enough jobs from any group / user.<br>
<br>base       
8.5%     -<br>lhcatlas   
38.46% 37.42% 

<br>lhccms    
23.53% 22.16% 

<br>lhclhcb     14.81% 14.39% 

<br>lhtier2     
14.48% 14.24% 

<br>localat3   
0.16% 1.9% 

<br>magic      
0.06% 3.8% 

<br>pau         
0.0% 3.8% <br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So to your numbers.  If the cluster is at 70% either a lot of work finished at once or nobody has been queuing work for a while. If the latter is true, probably one person will queue first and fill most of the 30% (if they have enough jobs).  When someone else submits jobs, if enough time has passed, fair-share with kick in and their jobs will get the higher start priority.  If it&#39;s the former, jobs at the top of the priority list should get started.  If the main factor is fair-share then this probably means mostly one persons jobs so they can catch up to their target.<br>
</blockquote><div><br>This example you&#39;re talking about is a compressive scenario, but we&#39;re assuming that we have no queued jobs. But that IDLE 30% could be due to a drain of some blades of our farm, so, when we set all those nodes online again (with more than 1k jobs in queue)  and maui not seeing the &quot;real&quot; queue, it&#39;s goint to fill up the farm without respecting FS.<br>
<br>Maybe this situations isn&#39;t the most critical (I could control it by hand), but I&#39;m really worried about the normal scheduling cycle we see in our farm.<br>Last week we gave IDLE limit a new oportunity and we saw really bad results.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If you have lost of very small jobs, well that is a challenge.  Perhaps you can demonstrate to your users how to aggregate them into modest groups to get maybe 1-2hr jobs.  Their overall throughput might increase...  It might also be work that no-one wants to do.<br>
</blockquote><div><br>Unfortunately 85% of our jobs are grid  jobs, and changing &quot;users&quot; behaviour is really complicated.<br><br>I&#39;ll play with NODEPOLLFREQUENCY and JOBAGGREGATIONTIME and see if I get an increase of maui performance.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Gareth<br></blockquote><div><br>Many thanks for your help Gareth,<br>Cheers,<br>Arnau <br></div></div>