[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] CPU scheduling and allocated all VCPU.

Hi Austin,

  Many thanks for your explanation.  If xen automatically load-balances the VCPUs dynamically then how would this impact performance for all VMs when they have been allocated all VCPUs?  To my database colleagues dynamic load balancing seems good.


On 2014-07-01 14:32, Austin S Hemmelgarn wrote:

On 2014-07-01 08:07, Sophie wrote:
Hi, We have lots of virtual machines running our Oracle Virtual Manager setup ( Oracle Linux with Xen) on x86. When I've setup new VMs I've always assigned CPUs to them instead of sharing them because all our VMs run RHEL and Oracle 11g. In my opinion this ensures they have all CPU cycles dedicated without any chance they'll be starved. Their combined SGA and PGA usually total 3Gb and I've allocated 4Gb of dedicated RAM. 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? Thanks, Sophie
I think that they have failed to understand that when you don't bind
VCPUs to physical CPUs, xen automatically load-balances the VCPUs
dynamically.  Personally, I would keep the same number of VCPUs assigned
to each VM, but not pin them to specific physical CPUs (with the notable
exception of giving Domain-0 pinned VCPUs, and making sure that the VM's
don't run on those physical CPUs).  In my experience, this tends to get
better performance with I/O heavy workloads such as most database work.
 I would not, however, suggest over-provisioning VCPUs by more than
twice the number of physical CPUs.

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.