On Sun, Apr 6, 2014 at 3:18 PM, Gilad Chaplik <gchaplik(a)redhat.com> wrote:
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Liran Zelkha" <liran.zelkha(a)gmail.com>
> Cc: "Gilad Chaplik" <gchaplik(a)redhat.com>,
devel(a)linode01.ovirt.org,
"engine-devel" <engine-devel(a)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(a)redhat.com
> > <mailto:iheim@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?