<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 6, 2017 at 8:10 PM Nir Soffer <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 5:57 PM Roy Golan <<a href="mailto:rgolan@redhat.com" target="_blank">rgolan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi all, <br><br></div>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.<br><br></div><div>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.<br><br>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. <br><br><div>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.<br></div><div><br></div></div><div>Pros<br></div><div>- Engine has rore resources to support more hosts/vms/other activities of the engine<br></div><div>- Vdsm will have more resources as well (need to tweak vdsm to collect in the same <br>frequency)<br></div><div>- 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)<br></div><div><br></div><div>Cons<br></div><div>- DWH/Dashboard will have less entries, I'm not sure what is graphical affect given our hourly resolution (cmiiw here)</div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Why we have a monitoring interval at all? why not move the stats to events?</div><div><br></div></div></div></blockquote><div><br></div><div>Events is not suited for everything and the current vdsm can only guarantee 'at most once' semantics. We can not rely on that and that is why we poll. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Vdsm should collect stats and send updates to engine, engine can do only</div><div>polling only if vdsm did not send any update in the last couple of minutes or so.</div><div><br></div></div></div></blockquote><div>Again you'd have to work harder to guarantee it . One of my main motivations here is to put as little effort as we can to gain more resources.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Same for stats collected by collectd, we want to stream updates to engine from</div><div>the host, no poll every host for the stats.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div></div></div></blockquote><div>Again, not always - consider this, for example if we want to support big setups, in the end they are going to stream huge amount of information to the engine - we would have a problem handling this pressure. Poll will allow us to choose who to poll and when. (backpressure if that helps) <br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Nir</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><br>[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1430876" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1430876</a><br></div>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a></blockquote></div></div></blockquote></div></div>