On Nov 12, 2013, at 11:18 , Tomas Jelinek <tjelinek(a)redhat.com> wrote:
So we have looked into the resource usage sampling with mbetak and
also with Michal and it seems that
for the CPU usage:
- VDSM polls libvirt to get the runtime statistics of the VM regularly. The pooling
interval is configured in
vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds
- libvirt returns something we than use to calculate the average CPU usage since the last
poll
- engine polls VDSM once in 15 seconds to get the current statistics (the same 15 seconds
is just a coincidence and we can not count on this)
- than the frontend polls the engine each 5-60 seconds (depends on the refresh rate) and
gets the current value from the engine
- the user can press the refresh button anytime to poll the engine again
For network usage:
- it should be pretty much the same as the CPU just the VDSM poll interval is configured
as vm_sample_net_interval and by default it is 5 seconds
Dan, since we poll only every 15s and cpu info is 15s wouldn't it make sense to change
the default for network monitoring to 15s as well? it's 2 libvirt rounds trip for
nothing really. Or does it serve some other purpose?
For memory usage:
- guest agent sends a message to VDSM with the memory usage regularly. The interval is
set in ovirt-guest-agent.conf as heart_beat_rate
and by default it is 5 seconds
- the actual value sent by ovirt-guest-agent is the actual value at the time when the
value is sent (e.g. for Linux taken from "cat /proc/meminfo")
- vdsm is doing no statistics on top of it, just remembers the last value taken from
ovirt-guest-agent
which is fine, it doesn't change so often and there are typically no spikes
- the rest of the poling is the same
So, visualizing this in some usable form will be quite challenging ;)
I see the following problems:
- if the VDSM gets the data faster than the engine polls it (and most often it does) than
the info in between will be lost.
The question is how big this problem is and if it is worth solving (I would say not for
CPU which are averages but maybe yes for memory).
Other question if there is a way how to solve it since the VDSM can be polled by anyone
and it does not really care if someone polls it... (Michal?)
I'd say not solve it and try to keep it in sync on vdsm side with engine poll, to save
unnecessary libvirt calls
- we can lost some data between frontend<->engine if the
polling interval of the FE is slower than the polling interval of the engine. This is
something
not really worth solving because the user can set this according to the level of detail
he/she wants
well, you should average the values in engine in case the FE refresh is >15s. Or add
(refresh/15) of them
- since we will get new info once in ~15 seconds, and the polling of
the FE is by default 5 seconds, do we want to do some interpolation? Or just show the
same value 3 times? Or be smart and show only changed values? (this is tricky since
there is a chance that it did not change - e.g. constant 0 mem usage if you have no guest
agent)
- What if the user starts clicking to the refresh button? Do we want to keep appending
the same value if the engine still has only the old ones?
just add a new line/point every 15s should be ok
Thanks,
michal
Tomas
----- Original Message -----
> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
> To: "Malini Rao" <mrao(a)redhat.com>
> Cc: "Eldan Hildesheim" <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org,
"info" <info(a)eldanet.com>
> Sent: Monday, November 11, 2013 4:23:09 PM
> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>
>
>
> ----- Original Message -----
>> From: "Malini Rao" <mrao(a)redhat.com>
>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "info"
<info(a)eldanet.com>,
>> engine-devel(a)ovirt.org
>> Sent: Monday, November 11, 2013 4:15:50 PM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>> Is this going to fit in a row of a table? Or are we talking of a more
>> detailed view?
>
> it should fit into one cell of the table
>
>>
>> ----- Original Message -----
>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
>> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
>> Sent: Monday, November 11, 2013 8:01:07 AM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>> Throw this gif into a browser. This is more or less what I thought.
>> Eldan
>>
>> ----- Original Message -----
>> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
>> To: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "info"
<info(a)eldanet.com>,
>> engine-devel(a)ovirt.org
>> Sent: Monday, November 11, 2013 12:03:15 PM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>>
>>
>> ----- Original Message -----
>>> From: "Eldan Hildesheim" <ehildesh(a)redhat.com>
>>> To: "Einav Cohen" <ecohen(a)redhat.com>
>>> Cc: "info" <info(a)eldanet.com>, engine-devel(a)ovirt.org
>>> Sent: Sunday, November 10, 2013 3:56:57 PM
>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>
>>> Hello all,
>>> We use to have a good solution in the period pre-WPF.
>>> A line chart (used to be in flash) that works like a plotter:
>>> The Line Bar (not bar) had a small animation that shifted all the bar to
>>> the
>>> left.
>>> When a new data arrived it just added a new line (to the right) and as I
>>> said
>>> before, in parallel it always shifted slowly to the left.
>>
>> Any chance you still have some screenshot or mockup so I can imagine it
>> better?
>>
>>> The animation gives the impression that data is streaming and when a real
>>> new
>>> data arrives the user gets it very fast.
>>> We have to sync between the animation and the rate of the arrival of the
>>> data
>>> but this is easy.
>>> If we can't find a good framework it can be created from scratch with
JS,
>>> svg
>>> or canvas.
>>
>> We need to be careful about what we will use. oVirt is supposed to work on
>> FF
>> 17 [1]
>> but the HTML5 canvas works only since FF23 [2].
>>
>> @Einav:
>> Is there a chance that we could start support only FF23+ and IE9+ (this one
>> is already OK)
>> because of this feature?
>>
>>> Now regarding its position:
>>> Rollover is good but not enough, we should somehow put it in the lower
>>> panel
>>> under general or even another tab - (live data).
>>
>> This is a bit different requirement. The point of this specific is to give
>> a
>> better
>> overview in the main tab. If it will be done we can decide if we want to
>> give
>> more
>> details in sub tabs.
>>
>>> We could later on have a (live data Tab) in other places as well like
>>> host,
>>> cluster...
>>> Eldan
>>
>> [1]:
http://www.ovirt.org/Download
>> [2]:
http://caniuse.com/#feat=canvas
>>
>>>
>>> ----- Original Message -----
>>> From: "Einav Cohen" <ecohen(a)redhat.com>
>>> To: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
>>> Cc: "Alexander Wels" <awels(a)redhat.com>, "Eldan
Hildesheim"
>>> <ehildesh(a)redhat.com>, engine-devel(a)ovirt.org, "info"
<info(a)eldanet.com>
>>> Sent: Friday, November 8, 2013 10:50:10 PM
>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>
>>>> ----- Original Message -----
>>>> From: "Ewoud Kohl van Wijngaarden"
<ewoud+ovirt(a)kohlvanwijngaarden.nl>
>>>> Sent: Thursday, November 7, 2013 11:44:07 AM
>>>>
>>>> On Wed, Nov 06, 2013 at 11:45:36AM -0500, Alexander Wels wrote:
>>>>> I suppose we need to answer a few questions before we can go into
>>>>> which
>>>>> library is better:
>>>>>
>>>>> 1. Do we mind sending data over to Google so Google can render
images
>>>>> for
>>>>> us.
>>>>
>>>> I'd say no. Even from a reliability point of view since users may
have
>>>> systems that aren't connected to the internet.
>>>
>>> +1
>>>
>>>> (Though I don't know how well oVirt handles this currently.)
>>>
>>> AFAIK - oVirt is handling it ('it' == having no internet
connection)
>>> well.
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>