[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] VM CPU/Disk unexplained increase in resize time
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] VM CPU/Disk unexplained increase in resize time |
Date: |
Mon, 1 Aug 2016 11:44:31 +0200 |
On Fri, 29 Jul 2016 11:30:00 +0100
"Chathura M. Sarathchandra Magurawalage" <address@hidden> wrote:
> Hi,
>
> Does anyone know the reason for, VM resizing time to increase faster if you
> continuously increase CPU or DISK resources by +1 (e.g. 1-2, 2-3, 3-4, 4-5).
> Whereas, when you increase from 1 to any other (e.g. 1-2, 1-2, 1,3, 1-4, 1-5)
> it takes less time in comparison. Can anyone give an explanation for this? I
> have plotted two graphs.
>
> https://www.dropbox.com/s/5e8xrrctu0rcwx3/CPU%20scaling%20%20-%20continuous%20vs%20increasing%20from%201.png?dl=0
> https://www.dropbox.com/s/txpkb8k6mpyexv8/CPU%20scaling%20-%20increase%20from%201.png?dl=0
>
> The first graph shows the VM CPU resize time (y axis) vs number of vCPUs (x
> axis) of continuous (blue) and resize from a VM with 1 vCPU (green)
> scenarios.The second graph shows the VM CPU resize time (y axis) vs number of
> vCPUs (x axis), when resized from a VM with 1 vCPU at each step (The green
> line in first graph). The error bars show the standard error of the gathered
> values at each step, as I did resize multiple times to get a mean value. I
> use openstack on x86 with KVM, although I have asked the openstack community
> I could not yet find an answer to this.
>
> Thanks!
>
QEMU can add CPUs only by one CPU object at a time so from QEMU's
point of view time of hotplugging a CPU more or less constant.
I'd look farther up the stack for issue.
CCing Peter,
who might look at it from libvirt perspective.