Databases Reference
In-Depth Information
Where does the missing resource come from? Behaviors such as resource sharing, scheduling, and
time-slicing are used by hypervisors to make each virtual server appear to have full access to the
physical resources that it's allocated all of the time. Under the hood, however, the hypervisor is busy
managing resource request queues — for example, “pausing” virtual servers until they get the CPU
time they need, or pre-empting a number of requests on physical cores while the hypervisor waits
for another resource they need to become available.
How much this contention affects the performance of virtual servers depends on how the hypervisor
you're using works. In a worst-case scenario using VMware, a virtual server with a large number
of virtual CPUs can be signii cantly affected if running alongside a number of virtual servers with
small numbers of virtual CPUs; this is due to VMware's use of their co-scheduling algorithm to
handle CPU scheduling. Seeing multi-second pauses of the larger virtual server while it waits for suf-
i cient physical CPU resources is possible in the worst-case scenarios, indicating not only the level of
attention that should be paid to deploying virtual servers, but also the type of knowledge you should
have if you're going to be using heavily utilized virtual environments.
Although that example of how VMware can affect performance is an extreme example, it does show
how bad contention introduces unpredictable latency. Previously, on a host server with uncontended
resources, you could effectively assume that any virtual server's request for a resource could be
fuli lled immediately as the required amounts of resource were always available. However, when
the hypervisor has to manage contention, a time penalty for getting access to the resource gets
introduced. In effect, “direct” access to the physical resource by the virtual server can no longer be
assumed.
“Direct” is in quotes because although virtual servers never directly allocate to themselves the
physical resources they use in an uncontended situation, the hypervisor does not have difi culty
i nding the requested CPU time and memory resources they require; the DBA can know that any
performance penalty caused by virtualization is likely to be small but, most important, consistent.
In a contended environment, however, the resource requirements of other virtual servers now have
the ability to affect the performance of other virtual servers, and that becomes un-predictable.
Demand-Based Memory Allocation
I mentioned earlier that some hypervisors offer features that aim to reduce the amount of physical
memory needed in a virtual environment's host servers. Memory is still one of the most expensive
components of a physical server, not so much because of the cost per GB but because of the number
of GBs that modern software requires in servers. It's not surprising therefore that virtualization
technologies have tried to ease the cost of servers by making what memory is installed in the
server go farther. However, there is no such thing as free memory; and any method used to make
memory go farther will affect performance somewhere. The goal is to know where that performance
impact can occur with the least noticeable effects.
Demand-based memory allocation works on the assumption that not all the virtual servers running
on a host server will need all their assigned memory all the time. For example, my laptop has 4GB of
memory but 2.9GB of it is currently free. Therefore, if it were a virtual server, the hypervisor could
get away with granting me only 1.1GB, with the potential for up to 4GB when I need it. Scale that
out across a host server running 20 virtual servers and the potential to i nd allocated but
un-required memory could be huge.
Search WWH ::
Custom Search