7:37 a.m.
Joining in...
From my point of view, in real life a user should have that many VDSs
on one Engine (from a DB point of view).
Modern DB system handles tables with
millions of records and many relations, Do we really have a performance issue here?
We could prefer a more easy to maintain implantation in this case over DB performance
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
To: "Liran Zelkha" <liran.zelkha(a)gmail.com>
Cc: devel(a)linode01.ovirt.org, "engine-devel" <engine-devel(a)ovirt.org>
Sent: Sunday, April 6, 2014 3:32:26 PM
Subject: Re: [Devel] [Engine-devel] vds_dynamic refactor
----- Original Message -----
> From: "Liran Zelkha" <liran.zelkha(a)gmail.com>
> To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> Cc: "Itamar Heim" <iheim(a)redhat.com>, devel(a)linode01.ovirt.org,
> "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Sunday, April 6, 2014 3:26:24 PM
> Subject: Re: [Engine-devel] vds_dynamic refactor
>
> 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.
Of course it is, that was a rhetorical question :-) (a lot of emoticons and
LOLs ;-))
>
>
> > Still holds my original thought for having vds_on_boot.
> >
> >
> >
> Let's talk f2f on Tuesday?
I'd prefer to reach conclusions here, I'd like everyone to be involved in a
root issue like this one.
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel