<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 8/12/15 1:49 PM, Sachin Manpathak
      wrote:<br>
    </div>
    <blockquote
cite="mid:CADH8PtPBvYixct=jVxkU9TV_EXeJmEr9Vr7vtyT=DuohGdfcVg@mail.gmail.com"
      type="cite">
      <div dir="ltr">Thanks, This feedback was helpful.
        <div>Perhaps my paraphrasing was misleading. I am not running
          openstack at scale in order to see how much the DB can
          sustain. My observation was that the host running nova
          services saturates on CPU much earlier than the DB does. </div>
      </div>
    </blockquote>
    You absolutely *want* a single host to be saturated *way* before the
    database is; the database here is a single vertical service intended
    to serve hundreds or thousands of horizontally scaled clients
    simultaneously.    A single request at a time should not even be a
    blip in the database's view of things.<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CADH8PtPBvYixct=jVxkU9TV_EXeJmEr9Vr7vtyT=DuohGdfcVg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Joins could be one of the reasons. I also observed that
          background tasks like instance creation, resource/stats
          updates contend with get queries. In addition to caching
          optimizations prioritizing tasks in nova could help.</div>
        <div><br>
        </div>
        <div>Is there a nova API to fetch list of instances without
          metadata? Until I find a good way to profile openstack code,
          changing the queries can be a good experiement IMO.</div>
        <div><br>
        </div>
        <div> </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Aug 12, 2015 at 8:12 AM, Dan
          Smith <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class="">> If OTOH we are referring to the width of the
              columns and the join is<br>
              > such that you're going to get the same A identity
              over and over again,<br>
              > if you join A and B you get a "wide" row with all of
              A and B with a very<br>
              > large amount of redundant data sent over the wire
              again and again (note<br>
              > that the database drivers available to us in Python
              always send all rows<br>
              > and columns over the wire unconditionally, whether or
              not we fetch them<br>
              > in application code).<br>
              <br>
            </span>Yep, it was this. N instances times M rows of
            metadata each. If you pull<br>
            100 instances and they each have 30 rows of system metadata,
            that's a<br>
            lot of data, and most of it is the instance being repeated
            30 times for<br>
            each metadata row. When we first released code doing this, a
            prominent<br>
            host immediately raised the red flag because their DB
            traffic shot<br>
            through the roof.<br>
            <span class=""><br>
              > In this case you *do* want to do the join in<br>
              > Python to some extent, though you use the database to
              deliver the<br>
              > simplest information possible to work with first; you
              get the full row<br>
              > for all of the A entries, then a second query for all
              of B plus A's<br>
              > primary key that can be quickly matched to that of A.<br>
              <br>
            </span>This is what we're doing. Fetch the list of instances
            that match the<br>
            filters, then for the ones that were returned, get their
            metadata.<br>
            <span class="HOEnZb"><font color="#888888"><br>
                --Dan<br>
              </font></span>
            <div class="HOEnZb">
              <div class="h5"><br>
__________________________________________________________________________<br>
                OpenStack Development Mailing List (not for usage
                questions)<br>
                Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
                  rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                  rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>