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

Thu Jul 6 15:33:23 UTC 2017

We will probably keep it at 20 seconds in any case for CFME.
But first let's measure the benefit, added a needinfo in the bug.

Thanks,

YANIV LAVI (YANIV DARY)

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. <https://www.redhat.com/>

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

ylavi at redhat.com    T: +972-9-7692306/8272306     F: +972-9-7692223    IM: ylavi
 <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@redhatnews <https://twitter.com/redhatnews>   Red Hat
<https://www.linkedin.com/company/red-hat>   Red Hat
<https://www.facebook.com/RedHatInc>

On Thu, Jul 6, 2017 at 4:37 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 Thu, Jul 6, 2017 at 12:39 PM, Oved Ourfali <oourfali at redhat.com> wrote:
>
>>
>>
>> On Thu, Jul 6, 2017 at 12:19 PM, Roy Golan <rgolan at redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Jul 6, 2017 at 12:18 PM Roy Golan <rgolan at redhat.com> wrote:
>>>
>>>> Action items:
>>>> - Demonstrate the effect of the reduction of stats collection on the
>>>> system - WIP
>>>> - Code changes:
>>>>   - config item change: NumberVmRefreshesBeforeSave from 5 to 10
>>>>   - make the 'poll' vms job to fire at NumberVmRefreshesBeforeSave / 2
>>>> (or just make the code to support explicit time interval)
>>>>   - VDSM should get a config set with the sampling inteval - to support
>>>> back-compat
>>>>
>>>> - Chages to DWH sampling and ManageIQ?
>>>
>>
>> I think manageIQ can cope with either 60 seconds or 20 seconds intervals
>> (after a change we've made when we moved to 20 seconds).
>> Put an action item indeed to check that with us if we'll decide to do so.
>>
>
> Indeed 20 or 60 seconds. Their implementation is very strict and coupled
> with vmware statistics which are 20 seconds.
>
>
>>
>>
>>>
>>>>
>>>>
>>>> On Thu, Jul 6, 2017 at 11:00 AM Yaniv Kaul <ykaul at redhat.com> wrote:
>>>>
>>>>> On Thu, Jul 6, 2017 at 10:04 AM, Oved Ourfali <oourfali at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 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 thought it was configurable in ManageIQ how often to query, but in
>>>>> any case even if we query every 20 seconds, we'll get updated VM stats,
>>>>> which is fine, and not as updated hosts stats, which is fine as well, from
>>>>> my perspective.
>>>>> Y.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/bcec2047/attachment-0001.html>