Hi Lenz,

That PR will need a lot of rebasing, as there's been later changes to the
rbd controller.

Nevertheless, while working on that I found a few quick wins that could be
easily implemented (I'll try to come back at this in the next weeks):

   - Caching object instances and using flyweight objects for ioctx,
   rbd.Images, stat, etc.
   - Removing redundant (heavyweight) call to RBDConfiguration.
   - Moving the actual disk usage calculation out of the 60-second loop.
   IMHO that info should be provided by RBD, perhaps calculated and cached in
   the rbd_support mgr module (@Jason)?

However that endpoint, if used with multiple RBD pools, namespaces, clones
and snapshots, is gonna have a hard time (O(N^4)-like) as it's fully serial.

Any other ideas?

@Matt: just curious, apart from the number of images, what's the amount of
rbd pools/clones/snapshots/... on your deployment?

Kind regards,

Ernesto Puerta

He / Him / His

Senior Software Engineer, Ceph

Red Hat <https://www.redhat.com/>

On Mon, Jan 6, 2020 at 6:08 PM Lenz Grimmer <lgrim...@suse.com> wrote:

> Hi Matt,
> On 1/6/20 4:33 PM, Matt Dunavant wrote:
> > I was hoping there was some update on this bug:
> > https://tracker.ceph.com/issues/39140
> >
> > In all recent versions of the dashboard, the RBD image page takes
> > forever to populate due to this bug. All our images have fast-diff
> > enabled, so it can take 15-20 min to populate this page with about
> > 20-30 images.
> Thanks for bringing this up and the reminder. I've just updated the
> tracker issue by pointing it to the current pull request that intends to
> address this: https://github.com/ceph/ceph/pull/28387 - looks like this
> approach needs further testing/review before we can merge it, it
> currently is still marked as "Draft".
> @Ernesto - any news/thoughts about this from your POV?
> Thanks,
> Lenz
> --
> SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nuernberg
> GF: Felix Imend├Ârffer, HRB 36809 (AG N├╝rnberg)
ceph-users mailing list

Reply via email to