<div dir="ltr">Hi Tony,<div>Interesting findings. Yes that does seem like a bug with polling_interval. All of the logic to make a load balancing decision is done in _eval_add_node and doesn&#39;t consider average job duration. It was a design decision at the time: look at the queue and current slot count to see if throughput meets the parameter <span style="color:rgb(51,51,51);font-family:Consolas,&#39;Liberation Mono&#39;,Menlo,Courier,monospace;font-size:12px;line-height:16.8px;white-space:pre">longest_allowed_queue_time</span>, or whether we should try to predict job durations. We surveyed some of the most active users at that time and most said their job sizes were varying and unpredictable and not amenable to &#39;prediction&#39;. So we went with the former.</div><div><br></div><div>Thanks for sharing your findings, but I&#39;m not sure why you seem cranky that the ELB isn&#39;t meeting your predictive load balancing needs and has some bugs in unused code? It&#39;s open source for a reason, so people can adapt and improve it.</div><div>best,</div><div>Raj</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 3, 2016 at 8:41 AM, Tony Robinson <span dir="ltr">&lt;<a href="mailto:tonyr@speechmatics.com" target="_blank">tonyr@speechmatics.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Okay, I&#39;ve found another bug with the
      load balancer which explains why avg_job_duration() was getting
      shorter and shorter.<br>
      <br>
      get_qatime() initially loads the whole (3 hours) history, but
      after that sets  temp_lookback_window = self.polling_interval<br>
      <br>
      The problem with this is self.polling_interval has to be much
      shorter than a job duration (it&#39;s got to be able to keep up) and
      the -b option to qacct sets &quot;The earliest start time for jobs to
      be summarized,&quot;, so it only selects jobs that have been started
      recently and finished (so that they get into qacct) - hence they
      must be the very short jobs.   Hence the cache is originally
      populated quite reasonably but then only gets updated with very
      short jobs, all the long ones never get into the cache.<br>
      <br>
      As I say below, I don&#39;t think any of this code is used anyway so
      it doesn&#39;t matter too much that it&#39;s all broken.<br>
      <br>
      I&#39;ll progress with my (weekend and part time) clean up and
      implementation of a true predictive load balancer.  I have both
      (a) mean and variance for all job types and (b) working code
      assuming that avg_job_duration() is correct, so it&#39;s probably only
      another days work to get solid (or a month or two of elapsed time,
      I&#39;m done for this weekend).<span class="HOEnZb"><font color="#888888"><br>
      <br>
      <br>
      Tony</font></span><div><div class="h5"><br>
      <br>
      On 01/04/16 17:01, Tony Robinson wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      
      <div>On 01/04/16 16:22, Rajat Banerjee
        wrote:<br>
      </div>
      <blockquote type="cite">
        <div dir="ltr">
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>Regarding:<br>
                      How about we just call qacct every 5 mins, or if
                      the qacct buffer is empty. <br>
                    </div>
                    <div>calling qacct and getting the job stats is the
                      first part of the load balancers loop to see what
                      the cluster is up to. I prioritized knowing the
                      current state, and keeping the LB running it&#39;s
                      loop as fast as possible (2-10 seconds), so it
                      could run in a 1-minute loop and stay roughly
                      on-schedule. It&#39;s easy to run the whole LB loop
                      with 5 minutes between loops with the command line
                      arg <span>polling_interval, if that
                        suits your workload better. I do not mean to
                        sound dismissive, but the command line options
                        (with reasonable defaults)are there so you can
                        test and tweak to your work load.<br>
                      </span></div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </blockquote>
      <br>
      Ah, I wasn&#39;t very clear.   What I mean is that we only update the
      qacct stats every 5 minutes.   I run the main loop every 30s.   <br>
      <br>
      But calling qacct doesn&#39;t&#39; take any time - we could do it every
      polling interval:<br>
      <br>
      root@master:~# date<br>
      Fri Apr  1 16:54:31 BST 2016<br>
      root@master:~# echo qacct -j -b `date +%y%m%d`$((`date +%H` -
      3))`date +%m`<br>
      qacct -j -b 1604011304<br>
      root@master:~# time  qacct -j -b `date +%y%m%d`$((`date +%H` -
      3))`date +%m` | wc<br>
        99506  224476 3307423<br>
      <br>
      real    0m0.588s<br>
      user    0m0.560s<br>
      sys    0m0.076s<br>
      root@master:~# <br>
      <br>
      <br>
      If calling qacct is slow then the update could be run at the end
      of the loop so it would have all of the loop wait time to complete
      in.<br>
      <br>
      <blockquote type="cite">
        <div dir="ltr">
          <div>
            <div>
              <div>
                <div>
                  <div>Regarding:<br>
                  </div>
                  Three sorts of jobs, all of which should occur in the
                  same numbers,<br>
                </div>
                Have you tried testing your call to qacct to see if it&#39;s
                returning what you want? You could modify it in your
                source if it&#39;s not representative of your jobs:<br>
                <a href="https://github.com/jtriley/StarCluster/blob/develop/starcluster/balancers/sge/__init__.py#L528" target="_blank">https://github.com/jtriley/StarCluster/blob/develop/starcluster/balancers/sge/__init__.py#L528</a><br>
                qacct_cmd <span>=</span> <span><span>&#39;</span><tt>qacct -j -b </tt><span>&#39;</span></span> <span>+</span>
                qatime<br>
              </div>
            </div>
          </div>
        </div>
      </blockquote>
      <br>
      Yes, thanks, I&#39;m comparing to running qacct outside of the load
      balancer.<br>
      <br>
      <blockquote type="cite">
        <div dir="ltr">
          <div>
            <div>
              <div>Obviously one size doesn&#39;t fit all here, but if you
                find a set of args for qacct that work better for you,
                let me know.<br>
              </div>
            </div>
          </div>
        </div>
      </blockquote>
      <br>
      At the moment I don&#39;t think that the output of qacct is used at
      all is it?   I thought it was only used to give job stats, I don&#39;t
      think it&#39;s really used to bring nodes up/down.<br>
      <br>
      <br>
      Tony<br>
      <br>
      <div>-- <br>
        Speechmatics is a trading name of Cantab Research Limited<br>
        We are hiring: <a href="http:www.speechmatics.com/careers" target="_blank">www.speechmatics.com/careers</a><br>
        Dr A J Robinson, Founder, Cantab Research Ltd<br>
        Phone direct: 01223 794096, office: 01223 794497<br>
        Company reg no GB 05697423, VAT reg no 925606030<br>
        51 Canterbury Street, Cambridge, CB4 3QG, UK<br>
      </div>
    </blockquote>
    <br>
    <br>
    <div>-- <br>
      Speechmatics is a trading name of Cantab Research Limited<br>
      We are hiring: <a href="https://www.speechmatics.com/careers" target="_blank">www.speechmatics.com/careers</a><br>
      Dr A J Robinson, Founder, Cantab Research Ltd<br>
      Phone direct: 01223 794096, office: 01223 794497<br>
      Company reg no GB 05697423, VAT reg no 925606030<br>
      51 Canterbury Street, Cambridge, CB4 3QG, UK</div>
  </div></div></div>

<br>_______________________________________________<br>
StarCluster mailing list<br>
<a href="mailto:StarCluster@mit.edu">StarCluster@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/starcluster" rel="noreferrer" target="_blank">http://mailman.mit.edu/mailman/listinfo/starcluster</a><br>
<br></blockquote></div><br></div>