|
Hi,
I would like to thank everybody for their time and really useful replies. With this onformation I have managed to nip early in the bud some possibly bad technical design decisions from being made by managers. I cannot thank you any much more :)
Kind regards, Sophie
On 2014-07-02 0:51, lee wrote:
Sophie <sophie@xxxxxxxxxxxx> writes:
Our DBA team, who were new to XEN and visualization seem to have a heightened interest in XEN and have asked me this: ** Why don't we allocated 32 VCPUS to all virtual machines so that they can share all resources and when they need CPUs they can access those that were sitting idle ** Their logic was VCPUs could be better distributed like this. My question to you is what do you think?
That's what I thought would make sense :) You probably don't want to do
that because it can cause delays when so many vCPUs are supposed to do
something that there is a lack of pCPUs.
I think it's better to make sure that dom0 and whatever VM others may
have to wait on get sufficient CPU in the first place. How much CPU
that is depends on workload.
All the rest of it also depends on workload. I have some VMs that
basically only need one CPU (or even less) because more CPUs doesn't
benefit what they are doing. I gave them 2 vCPUs because it won't hurt
anything when they sometimes might use 2 pCPUs, just in case that there
is something they can do in parallel and so that other VMs need not wait
on them. If other VMs had to wait (like on the answer to a DNS query),
their vCPUs would have to be idle anyway and it won't hurt anything to
have the idle pCPU do something instead (like helping to answer the DNS
query faster).
So you probably want to monitor what each VM does with its CPUs.
Perhaps none of them needs 32, perhaps some run as well with less and
some benefit from having more. Going by that, you can try to achieve
some optimum by giving VMs as few vCPUs as needed and by giving
additional vCPUs to other VMs that actually take advantage of them.
Letting all pCPUs as vCPUs to all VMs probably doesn't work as well as
trying to achieve such an optimum.
Overcommitting CPUs works fine --- probably up to some point at which
the pCPUs can't keep up, and/or at which overall performance goes down
due to pCPUs needing to access too many different memory areas.
I guess assigning, in total, about 1.75 times as many vCPUs as pCPUs is
a good measure to start with. Of course, it also depends on workload
and especially on timing ...
I'd start with assigning more vCPUs to the most busy VMs (provided that
the CPUs are actually used, and considering VMs that could become
bottlenecks) until 56 vCPUs (1.75x32) are assigned in total, see how it
goes and fine tune from there.
You might also want to tune the memory ...
|
