Databases Reference
In-Depth Information
no one-to-one mapping between a vCPU and a physical CPU core. Instead, a vCPU is a logical thread
that is put on a physical CPU core's queue when it has something to execute. The more requests
in the queue, the longer it takes for a thread to have its workload executed.
Additionally, another phenomenon unique to virtualization appears when a virtual server is
coni gured with multiple vCPUs. The hypervisor knows that if a physical server has four physical
CPU cores, then the operating system expects to be able to execute an instruction on all four
simultaneously; a very abstract example would be SQL Server executing a parallel query across four
logical CPUs, in which case SQL Server would expect all four CPUs to be available concurrently,
rather than have to wait for CPUs to become available.
VMware's relaxed co-scheduling algorithm is clever enough to know that if only two of a virtual
server's four vCPUs need to perform work, then only two physical CPU cores need to be found to
execute the virtual server's work. This can make managing concurrent virtual server workloads
more efi cient to manage, as the number of physical CPU cores needed is often much lower than you
would imagine. There can be issues with this approach though, when a virtual server that really
does need to use a large number of virtual CPUs has to compete with a large number of smaller vir-
tual severs with a low number of virtual CPUs. VMware's scheduling behaviors mean these smaller
virtual machines can jump on and off the CPUs faster, delaying the ability to schedule the single
much larger request for CPU time.
However, other hypervisors will only “run” the virtual server when enough physical CPU cores in
the host server are free to run each of the vCPUs concurrently. For example, if the virtual server
has four vCPUs assigned and the host server has 16 physical CPU cores, then the hypervisor would
have to wait until four of the 16 physical CPU cores were available before it could process any CPU
instructions from the virtual server. In this example if the host server was only running that virtual
server there shouldn't be any unnecessary latency, as with 16 physical cores available there will most
likely always be four available. It's only when virtual servers start competing between them for
a limited number of physical CPU cores that performance problems can occur.
As a consequence of this potential for CPU access latency, a general recommendation is for virtual
servers to be coni gured to have as few vCPUs as they actually need. That's not to say they can't
have a large number if they need them, but the assumption that the more you have the faster the
server will be may not always be correct.
Be aware that the virtual server itself is totally unaware of this latency, so it can only be monitored
from outside of the virtual server. High CPU latency will not, for example, incur high
SOS_SCHEDULER_YIELD
wait stats within SQL Server.
The latest generation of hypervisors now support large numbers of vCPUs per virtual sever.
VMware's vSphere 5 and Microsoft's Hyper-V in Windows Server 2012 both support assigning
32 vCPUs to a virtual server, an incredible amount of computing power but a capability that is
critical to their goal of being able to virtualize any workload. My only advice is to ensure that you
have adequate physical CPU cores in the host servers to support such a large number of vCPUs. The
physical CPU cores in the host server should not be overcommitted — that is, try to ensure that no
more than two vCPUs are assigned to running virtual servers per physical CPU core, although this
limit may need to be lower in demanding workload environments.
When considering how many vCPUs to assign to your virtual database server, I recommend using
previously captured performance data along with an understanding of your SQL Server workload.
Search WWH ::
Custom Search