Showing posts with label utilization. Show all posts
Showing posts with label utilization. Show all posts

Friday, 6 January 2017

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


Wednesday, 6 July 2016

Modeling Scenario (14 of 17) Capacity Management, Telling the Story

I have talked about bringing your KPI’s, resource and business data in to a CMIS and about using that data to produce reports in a clear, concise and understandable way.

Let’s now take a look at some analytical modeling examples, based on forecasts which were given to us by the business.

Below is an example of an Oracle box, we have been told by the business that we are going to grow at a steady rate of 10% per month for the next 12 months. We can model to see what the impact of that business growth will be on our Oracle system.

In the top left hand corner is our projected CPU utilization and on the far left of that graph is our baseline. You can see that over a few months we begin to go through our alarms and our thresholds pretty quickly.

Model – oracleq000 10% growth – server change



In the bottom left hand corner we can see where bottlenecks will be reached indicated by the large red bars which indicate CPU queuing.

On the top right graph we can see our projected device utilization for our busiest disk and we can see that within 4 to 5 months it is also breaching our alarms and thresholds.

Collectively these models are telling us that we are going to run in to problem with CPU and I/O.

In the bottom right hand graph is our projected relative service level for this application. In this example we started the baseline off at 1 second, this is key.

By normalizing the baseline at 1 second it is very easy for your audience to see the effect that these changes are likely to have. In this case, once we’ve added the extra workload we can see that we go from 1 second to 1.5 seconds (a 50% increase) and then jumped from 1 second to almost 5 seconds. From 1 to 5 seconds is a huge increase and one that your audience can immediately grasp and understand the impact of.

We would next want to show the model for change in our hardware and I'll be looking at this on Friday.

In the meantime why not join our Community and get access to a wealth of Capacity Management Resources http://www.metron-athene.com/_resources/

Charles Johnson
Principal Consultant

Monday, 4 July 2016

Business Metric Correlation (13 of 17) Capacity Management, Telling the Story

As mentioned previously it is important to get business information in to the CMIS to enable us to perform some correlations.

As in the example below we have taken business data and taken component data and we can now report on this together to see if there is some kind of correlation.

Business Transactions vs. CPU Utilization
In this example we can see that the number of customer transactions(shown in dark blue) reasonably correlates with the amount of CPU utilization.
Can we make some kind of judgment based on just what we see here? Do we need to perform some further statistical analysis on this data? What is the correlation co-efficiency for our application data against the CPU utilization?
Closer to the value of 1 indicates that there is a very close correlation between the application data and the underlying component data.
What can we do with this information back to the business? An example would be: This graph indicates that there is a very close correlation between the number of customer transactions and the CPU utilization. Therefore, if we plan on increasing the number of customer transactions in the future we are likely to need to do a CPU upgrade to cope with that demand.
On Wednesday I'll be looking at a Modeling scenario.
Charles Johnson
Principal Consultant