[ovirt-devel] Chaning the statistics monitoring interval to 30s

Oved Ourfali oourfali at redhat.com
Thu Jul 6 07:04:38 UTC 2017


On Thu, Jul 6, 2017 at 9:38 AM, Arik Hadas <ahadas at redhat.com> wrote:

>
>
> On Wed, Jul 5, 2017 at 9:36 PM, Shirly Radco <sradco at redhat.com> wrote:
>
>>
>>
>> --
>>
>> SHIRLY RADCO
>>
>> BI SOFTWARE ENGINEER,
>>
>> Red Hat Israel <https://www.redhat.com/>
>>
>> sradco at redhat.com
>>  <https://red.ht/sig>
>>  <https://redhat.com/summit>
>>
>>
>> On Wed, Jul 5, 2017 at 6:35 PM, Arik Hadas <ahadas at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Jul 5, 2017 at 5:57 PM, Roy Golan <rgolan at 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.
>>>>
>>>
>>> +1
>>>
>>>
>>>>
>>>> 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)
>>>>
>>>
>>> What's the frequency of the queries done by DWH/Dashboard? Do they count
>>> on the _update_date column of the queried data?
>>>
>>
>> Current frequency is 20 seconds.
>> The configurations are queried based on the _update_date, but  statistics
>> are queried every interval.
>>
>> The affect will be less accuracy in the hourly calculations.
>>
>
> Ack. So if the proposed change is done, it would probably make sense to
> increase the inverval of those queries to be higher than 30 sec, or at
> least taking into consideration the _update_date of vm_statistics as well.
>
>

Note that it will cause issues with cloudforms to change those queries to
30 seconds, so I guess we'll still query it every 20 seconds (although the
data won't change in some of those queries).



>>
>>> I'm asking because if they query the database every minute and say "the
>>> time now is 10:30 and the queried data is ..." then there should not be
>>> less entries.
>>>
>>>
>>>>
>>>>
>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1430876
>>>>
>>>
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170706/a2f861fa/attachment.html>


More information about the Devel mailing list