Hi all,
Current status of VdsUpdateRuntimeInfo (please note - patch is not yet committed).
Initial UpdateRuntimeInfo performance wasted roughly 57% of CPU time on DB activity. Of
that, about 25% of CPU time wasted on update behavior.
After modification (moving updates to batch update) UpdateRuntimeInfo performance wasted
roughly 40% of CPU time on DB activity. And only 12% of that was wasted on update
behavior.
My next task is to try and optimize the rest of overall database performance.
----- Original Message -----
From: "Liran Zelkha" <liran.zelkha(a)gmail.com>
To: "Barak Azulay" <bazulay(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Wednesday, June 12, 2013 12:35:03 PM
Subject: Re: [Engine-devel] Updates in VdsUpdateRuntimeInfo
Hi guys,
I'm working hard on this. I'll send summary mail and findings later today.
On Jun 12, 2013, at 10:45 AM, Barak Azulay wrote:
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Barak Azulay" <bazulay(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Wednesday, June 12, 2013 10:09:09 AM
> Subject: Re: [Engine-devel] Updates in VdsUpdateRuntimeInfo
>
> On 06/12/2013 09:41 AM, Barak Azulay wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim(a)redhat.com>
>>> To: "Liran Zelkha" <lzelkha(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>
>>> Sent: Tuesday, June 11, 2013 4:00:21 PM
>>> Subject: Re: [Engine-devel] Updates in VdsUpdateRuntimeInfo
>>>
>>> On 06/11/2013 03:26 PM, Liran Zelkha wrote:
>>>> Hi all,
>>>>
>>>> I'm checking performance for VdsUpdateRunTimeInfo.
>>>> Naturally, much of the performance surrounds database activity
>>>> (getVmsRunningOnVds queries, updateDeviceRuntimeInfo, updateVmDynamic)
>>>>
>>>> Few questions:
>>>> 1. I have implemented batch updates for procedure
>>>> UpdateVmDeviceRuntimeInfo
>>>> for improved performance.
>>>> 2. Seems like the only parameters UpdateVmDeviceRuntimeInfo is getting
>>>> are
>>>> vm_id,vm_device_id,address and alias. Are those rapidly changing, or
will
>>>> it be beneficial to implement caching on those updates (to ensure
>>>> not-required updates do not travel to the database).
>>>
>>> slowly changing, but how will you cover all flows changing these devices
>>> to invalidate the cache (iiuc, this table is modified by engine when
>>> adding devices to a VM as well?)
>>
>>
>> I don't think that in the device run time info we need to invalidate once
>> we add a device.
>> This is a specific case where we actually get the information from the VDSM
>> (addresses are received from libvirt)
>> The commands IIRC are first send to VDSM and than update the runtime info
>> only on changed info (we can also hash it),
>> It may put the placeholder in the DB first but it still relies on the data
>> received from VDSM.
>
> if this table is only updated from vdsm to save it, i agree.
> but isn't the engine also manipulating it?
> wasn't there a request to be able to maybe edit the addresses some day?
Even if there was such a request, we still update when we receive the info from libvirt.
Anyway there are obviously a few improvements to be done before caching.
- update only when info received from VDSM change (need to verify it is the practice
here)
- do batch update for the new updated data received.
- do the hashing (of vm device runtime info) on VDSM for the data , and update only when
hash changes
- caching ...
Barak
>
> _______________________________________________
> 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