[Devel] [Engine-devel] vds_dynamic refactor

Liran Zelkha liran.zelkha at gmail.com
Sun Apr 6 12:26:24 UTC 2014


On Sun, Apr 6, 2014 at 3:18 PM, Gilad Chaplik <gchaplik at redhat.com> wrote:

> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Liran Zelkha" <liran.zelkha at gmail.com>
> > Cc: "Gilad Chaplik" <gchaplik at redhat.com>, devel at linode01.ovirt.org,
> "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, April 6, 2014 11:33:12 AM
> > Subject: Re: [Engine-devel] vds_dynamic refactor
> >
> > On 04/06/2014 11:32 AM, Liran Zelkha wrote:
> > >
> > >
> > >
> > > On Sun, Apr 6, 2014 at 11:22 AM, Itamar Heim <iheim at redhat.com
> > > <mailto:iheim at redhat.com>> wrote:
> > >
> > >     On 04/03/2014 07:51 PM, Liran Zelkha wrote:
> > >
> > >         The problem is with both updates and selects.
> > >         For selects - to get all the information for the VDS we have
> > >         multiple
> > >         joins. Adding another one will hurt performance even more.
> > >         For updates - we have vds_static thats hardly changed.
> > >         vds_statistics
> > >         that changes all the time. vds_dynamic is not changed allot -
> but
> > >         is
> > >         updated all the time because of the status. I think it's best
> to
> > >         split
> > >         it to the two existing tables (BTW - relevant for VM as well)
> > >
> > >
> > >     but we don't update it unless the status has changed, which is a
> > >     rare occurance?
> > >
> > > Actually - no. We can definitely see times we are updating vds_dynamic
> > > with no reason at all. I tried to create patches for that - but it
> > > happens from many different places in the code.
> >
> > what would be updated vds_dyanmic for status not originating in update
> > run time info?
>
> We have separate DB flows for that (updateStatus and
> updatePartialVdsDynamicCalc and more in VdsDynamicDAODbFacadeImpl).
> A question: do you know if we update status in updateVdsDynamic? :-) not
> sure but I found a possible race for pending resources (cpu, mem), LOL :-)
>
> I think we do but not sure. Will check.


> Still holds my original thought for having vds_on_boot.
>
>
>
Let's talk f2f on Tuesday?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20140406/edad2cbc/attachment-0001.html>


More information about the Devel mailing list