Virtualization Oversubscription - What’s so scary? Why are we interested in queuing? (20 of 20)

The reason we were talking about queueing theory is that it’s part of how the hypervisor copes with CPU oversubscription, by queueing the VMs.

VMs Queue for free CPUs

·        Ready Time

·        Co-Stop time

·        Higher utilization = higher contention

·        More concerned about CPU busy than vCPU to logical CPU ratio

You can see when this starts to happen by monitoring ready and Co-Stop metrics.  You should typically be more worried about CPU busy than you are the ratio of CPUs in the VMs to the logical CPUs presented by the hardware.

Because all this is Math, people have written programs to model this, so you can see how busy you can run your hosts before performance becomes unacceptable.

Summary

If there is anybody reading this who considered oversubscription to mean poor performance then hopefully I’ve gone some way to showing you that’s not the case.

•        Oversubscription does not equal unacceptable performance

•        Virtualisation is expecting you to oversubscribe

–       It’s the reason it exists (Don’t throw that away.  It costs you money!)

•        Take the fear out of oversubscription through proper planning

–       Plan for performance, not ratios

Look at the metrics on your systems and use them to model the point where performance will degrade because of utilization.  You cannot do that by looking at the ratio of vCPUs to logical CPUs but you can with utilization figures. Thanks for following my blog series, if you have any questions please feel free to drop me a line.

If you'd like to learn more about managing VMware Capacity then why not try our Pay-to-View workshop

http://www.metron-athene.com/services/online-workshops/capacity-management-workshops.html

Phil Bell

Consultant

Virtualization Oversubscription - What’s so scary? Basic Ideas of Queuing (19 of 20)

Queueing theory is pretty simple.

You have a ‘server’.  Think of this as the CPU or the person sat at the checkout scanning groceries.  They work at a constant pace, and are fed with work from a queue.  The Queue is filled by transactions or customers. 

The response time of a transaction (from arriving to leaving), is the sum of the time spent queueing, and being served.  Given identical transactions, or customers, we know the service time is a constant, what can change is the Arrival rate and the time spent in the Queue.

Utilization and Response Time

What we have here is a chart showing response time on the Y-Axis and the utilization of the server on the X-Axis.

The reason the chart starts part way up the Y-Axis is the Service Time.  That’s static.  As the utilization of the server becomes higher the chance of the server being busy when a new transaction/customer arrives increases, and therefore the longer the transaction/customer will spend in the queue.  As we can see, it’s not a straight line.

All of this can be plotted using the formula R = S / (1-U).  Where S is the service time and U is the Utilization of the server.

Benefits of Multiple Servers

When we add in multiple Servers, the line ends up having a more sudden degradation. 

This change is sometimes known as “the knee of the curve”.  The more servers or CPUs we include the higher the utilization of them before the knee of the curve is observed.  This is because there is more chance that a CPU will be available at the moment a piece of work arrives.

Given most of the hosts in a virtualized environment are going to have high numbers of CPUs this means we can run them with pretty high utilizations before queueing takes over.

Consider though that a multiple vCPU VM needs multiple logical CPUs on the host available to do anything.

This has the effect of reducing the number of ‘servers’ or CPUs in the system.  If all your VMs are 4 vCPUs and you have 16 logical CPUs in the host that’s the equivalent of a 1 vCPU VM on a 4 CPU host. 

The moral of the story here is “use as few vCPUs as possible in each VM, and you’ll reduce queueing and improve performance.

Why are we interested in queuing? I'll answer that question in my final blog on Monday.

Phil Bell

Consultant

Virtualization Oversubscription - What’s so scary? 18 of 20

Happy New Year!

If you’ve been following my series then you’ll know that just before the Holidays I said that I’d deal with what’s the worst that can happen when you oversubscribe.

So what’s the worst that can happen?

Well if you push things too far, all those things that the Hypervisor can do to try and keep things running will eventually be overwhelmed.

If you try to use too much memory you’ll start to see ballooning on a consistent basis, then swapping.  At that point performance will degrade rapidly.  Watch active memory values and take ballooning increasing as the indication things are getting tight.

CPU is as always a more gentle decay in performance.  CPU also has it’s indicators that the limits are being approached.  CPU Ready and Co-Stop are indicators that VMs are finding it tricky to find CPUs when they want to do some processing.

The reason CPU degrades differently to Memory is that it’s used differently.  A process is in memory all the time, but only uses a CPU when it needs so CPU busy is dictated by how frequently the CPU is required and for how long.  The performance of a transaction will be dictated by the ‘chance’ that a CPU will not be available when the transaction arrives.  If all the CPUs are busy it’ll enter a queue and this is where queueing theory comes in.

Contention and Queuing

Any system has a finite set of resources.  If you only have a single user trying to use one workstation then there is no contention for the use of that workstation.  As soon as you have more than one user then there is a chance that they will want to use the workstation at the same time.  That’s contention.  It’s perfectly normal and happens inside every OS all the time.  There are lots more process threads than there are CPUs, and when there is contention, then the processes queue.  Poor performance only occurs when queueing becomes excessive.

On Friday I'll go in to more detail about the basic ideas of queuing. In the meantime register for our first webinar of 2017 'Performance Management made easy'

http://www.metron-athene.com/services/webinars/capacity-management-webinars.html

Phil Bell

Consultant