Make sense, Dan.
Thanks so much for your help.
Sergio
On Tue, Oct 23, 2018 at 5:01 PM Dan Smith wrote:
> > I tested a code change that essentially reverts
> > https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py
> >
> > In other words, with this change metadata tables are not
> I tested a code change that essentially reverts
> https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py
>
> In other words, with this change metadata tables are not fetched by
> default in API requests. If I understand correctly, metadata is
> fetched in separate queries as the
I tested a code change that essentially reverts
https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py
In other words, with this change metadata tables are not fetched by default
in API requests. If I understand correctly, metadata is fetched in separate
queries as the instance
https://bugs.launchpad.net/nova/+bug/1799298
On Mon, Oct 22, 2018 at 9:15 PM Sergio A. de Carvalho Jr. <
scarvalh...@gmail.com> wrote:
> Cool, I'll open a bug then.
>
> I was wondering if, before joining the metadata tables with the rest of
> instance data, we could do a UNION, since both tables
Cool, I'll open a bug then.
I was wondering if, before joining the metadata tables with the rest of
instance data, we could do a UNION, since both tables are structurally
identical.
On Mon, Oct 22, 2018 at 9:04 PM Dan Smith wrote:
> > Do you guys see an easy fix here?
> >
> > Should I open a
> Do you guys see an easy fix here?
>
> Should I open a bug report?
Definitely open a bug. IMHO, we should just make the single-instance
load work like the multi ones, where we load the metadata separately if
requested. We might be able to get away without sysmeta these days, but
we needed it for
Thanks so much for the replies, guys.
> Have you debugged to the point of knowing where the initial DB query is
starting from?
>
> Looking at history, my guess is this is the change which introduced it
for all requests:
>
> https://review.openstack.org/#/c/276861/
That is my understanding too.
> We haven't been doing this (intentionally) for quite some time, as we
> query and fill metadata linearly:
>
> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2244
>
> and have since 2013 (Havana):
>
> https://review.openstack.org/#/c/26136/
>
> So unless there has been a
> Of course this is only a problem when instances have a lot of metadata
> records. An instance with 50 records in "instance_metadata" and 50
> records in "instance_system_metadata" will fetch 50 x 50 = 2,500 rows
> from the database. It's not difficult to see how this can escalate
> quickly. This
On 10/22/2018 11:59 AM, Matt Riedemann wrote:
Thanks for this. Have you debugged to the point of knowing where the
initial DB query is starting from?
Looking at history, my guess is this is the change which introduced it
for all requests:
https://review.openstack.org/#/c/276861/
From that
On 10/22/2018 11:25 AM, Sergio A. de Carvalho Jr. wrote:
Hi,
While troubleshooting a production issue we identified that the Nova
metadata API is fetching a lot more raw data from the database than
seems necessary. The problem appears to be caused by the SQL query used
to fetch instance data
Hi,
While troubleshooting a production issue we identified that the Nova
metadata API is fetching a lot more raw data from the database than seems
necessary. The problem appears to be caused by the SQL query used to fetch
instance data that joins the "instance" table with, among others, two
12 matches
Mail list logo
