On Thu, Jul 6, 2017 at 7:10 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Wed, Jul 5, 2017 at 5:57 PM Roy Golan <rgolan(a)redhat.com>
wrote:
>
> Hi all,
>
> I would like to get feedback on $subject and see if I'm missing something.
> The impact of this is simply less resource consumption and by that we can
> support even greater number of hosts [1] and vms in the system.
>
> If you think more relaxed statistics collection will affect a core flow
> let me know - as far as I see I didn't spot anything critical.
>
> The overhead of a cycle per host something like that: 2 roundtrips per
> host in a cycle, (vm + host stats) and tons of memory allocation for char[]
> -> json-> maps of maps -> VM/Vds statistics -> Maps -> serialiazing to
DB.
>
> To minimize the effect of this change we can leave a call to 'list' verb
> to at least detect vms existence in the same rate as today.
>
> Pros
> - Engine has rore resources to support more hosts/vms/other activities of
> the engine
> - Vdsm will have more resources as well (need to tweak vdsm to collect in
> the same
> frequency)
> - less DB writes and reads, approx half of what the system will do in the
> in its lifefpan (cause this is what is mainly does all the time)
>
> Cons
> - DWH/Dashboard will have less entries, I'm not sure what is graphical
> affect given our hourly resolution (cmiiw here)
Why we have a monitoring interval at all? why not move the stats to events?
It was one of the main reason to build event infrastructure. I
advocated for this
many times but it seems that the priority to have it done is very low.
Less work is required to change the polling cycle than to trigger
events even for
the cost of metric resolution.
Vdsm should collect stats and send updates to engine, engine can do only
polling only if vdsm did not send any update in the last couple of minutes
or so.
Same for stats collected by collectd, we want to stream updates to engine
from
the host, no poll every host for the stats.
Nir
>
>
>
> [1]
https://bugzilla.redhat.com/show_bug.cgi?id=1430876
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel