CPU Overcommitment and Its Impact on SQL Server Performance on VMware

SQL Server Best Practices
SQL Server Best Practices
In the early days of virtualization, the core focus of virtualization was primarily consolidation. You could achieve quite high consolidation ratios, with some even as great as 20 to 1. This consolidation worked great for applications like file and print servers, development workloads, or other very lightly used servers. The virtualized servers that hold these servers are technically overcommitted on resources, but the workloads are so low that the end users would not notice the effects.

However, as more and more business-critical workloads are virtualized, maintaining this same level of consolidation is guaranteed to rear its ugly head in the form of performance degradation of the virtual machines. Most VMware administrators realize that resource overcommitment is slowing down their most intensive servers.

How can this be, you ask?

Few administrators know about a simple metric called CPU Ready.

What is CPU Ready?

Ponder this analogy for a minute.

Take a physical server, say with two CPU sockets and eight CPU cores in each sockets. You now have a total of 16 physical CPU cores in that server to use for virtual machine processing activity. I’m ignoring hyperthreading to keep things simple.

Let’s say now that you have ten virtual machines on this server, each with two virtual CPUs. You now have a situation where you are resource overcommitted, technically speaking. You have more than one virtual CPU allocated for every physical core.

This, in itself, is just fine. In fact, it is encouraged in just about every situation I can imagine.

But now, you know that each virtual CPU simply cannot get executed each and every time it needs to execute a command. It has to get into a queue so that it can be coordinated which process to execute next in line. I’ll call this the ‘Ready to Run’ queue.

Continue reading on DavidKlee.net.

54321
(0 votes. Average 0 of 5)