yahoo-eng-team team mailing list archive

[Johannes Kulik <2122109@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Listing server-groups can become slow the more server-groups there are
in a deployment.

While https://bugs.launchpad.net/bugs/2106380 has a specific reason for
this - accumulating deleted entries in instance_group_member table -
there are also other reasons without accumulating cruft.


One reason is that nova-api queries the not-deleted members from each cell, server-group by server-group. With a pagination limit of 1000, this can lead to 1000 * $number_of_cells queries against the DB. (`_get_not_deleted()` is called per server-group).


Another reason is, that nova-api queries all server-groups from the DB - fetching all the data and creating all the objects - and afterwards applies the limits/offset. This is highly inefficient if the number of server-groups is larger than the pagination limit.


Encountering the slowness and looking into it, we have downstream patches for both of these problems and would like to propose them upstream.

** Affects: nova
     Importance: Undecided
         Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2122109

Title:
  listing server-groups is slow

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Listing server-groups can become slow the more server-groups there are
  in a deployment.

  While https://bugs.launchpad.net/bugs/2106380 has a specific reason
  for this - accumulating deleted entries in instance_group_member table
  - there are also other reasons without accumulating cruft.

  
  One reason is that nova-api queries the not-deleted members from each cell, server-group by server-group. With a pagination limit of 1000, this can lead to 1000 * $number_of_cells queries against the DB. (`_get_not_deleted()` is called per server-group).

  
  Another reason is, that nova-api queries all server-groups from the DB - fetching all the data and creating all the objects - and afterwards applies the limits/offset. This is highly inefficient if the number of server-groups is larger than the pagination limit.

  
  Encountering the slowness and looking into it, we have downstream patches for both of these problems and would like to propose them upstream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2122109/+subscriptions