<div dir="ltr"><div dir="ltr"><div>Thanks so much for the replies, guys.</div><div><br></div><div>> Have you debugged to the point of knowing where the initial DB query is starting from?</div><div>></div><div>> Looking at history, my guess is this is the change which introduced it for all requests:</div><div>></div><div>> <a href="https://review.openstack.org/#/c/276861/">https://review.openstack.org/#/c/276861/</a></div><div><br></div><div>That is my understanding too. Before, metadata was fetched separately but this change meant that it both tables are always joined with other instance data.</div><div><br></div><div>I've debugged it to the point where the query gets built, in</div><div><br></div><div><a href="https://github.com/openstack/nova/blob/mitaka-eol/nova/db/sqlalchemy/api.py#L2005">https://github.com/openstack/nova/blob/mitaka-eol/nova/db/sqlalchemy/api.py#L2005</a></div><div><br></div><div>which results in a number of left outer joins by the "joinedload" calls, including to "instance_metadata" and "instance_system_metadata".</div><div><br></div><div>Most other tables have a single row for each instance (on our clusters, anyway), so the impact for us is simply down to metadata.</div><div><br></div><div>> Just to be clear, you don't have any modifications to the code anywhere, do you?</div><div><br></div><div>We do have some minor changes to Nova but nothing near instance, metadata or the ORM code.</div><div><br></div><div>Do you guys see an easy fix here?</div><div><br></div><div>Should I open a bug report?</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 22, 2018 at 7:17 PM Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> We haven't been doing this (intentionally) for quite some time, as we<br>
> query and fill metadata linearly:<br>
><br>
> <a href="https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2244" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2244</a><br>
><br>
> and have since 2013 (Havana):<br>
><br>
> <a href="https://review.openstack.org/#/c/26136/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/26136/</a><br>
><br>
> So unless there has been a regression that is leaking those columns back<br>
> into the join list, I'm not sure why the query you show would be<br>
> generated.<br>
<br>
Ah, Matt Riedemann just pointed out on IRC that we're not doing it on<br>
single-instance fetch, which is what you'd be hitting in this path. We<br>
use that approach in a lot of places where the rows would also be<br>
multiplied by the number of instances, but not in the single case. So,<br>
that makes sense now.<br>
<br>
--Dan<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a 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 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>
</blockquote></div>