Stand alone single thread optimized server vs vm running on VMWare

Question

I apologize for the length of my post.

We recently converted our business system to a product that is licensed by the number of Cores. We purchased the 2 core license and are currently running it on VMWare. It is quite expensive to move to the next license level.

We are having some pretty significant performance issues. We have eliminated RAM as a bottleneck, as well as network, database and disk access. The times we have issues are not always characterized by high CPU usages. Sometimes the cpu usage is less than 20%, but the CPU Ready is high.

I am pondering the possibility of running it directly on a separate physical server. Since I am limited to two cores I would select the fastest "Single Thread Performance" cpu I could get, likely 4 cores. Then I would set the business system up to use 2 cores and allow the OS to consume the other 2.

My logic goes something like this. Right now the VM is getting two threads or vCPU. This is really only one pCPU. Even if I moved it to the same box without hyperthreading it would get 2 full cores instead of 2 vCPU. But if I pick a chip that is much faster on single thread, I could gain significantly more. I would also likely have a small gain since I would not be virtualizing it any more.

Our current 6 core cpu gets the following scores according to Passmark. CPU Mark: 8570 Single Thread Performance: 1403

The 4 core processor I want gets these scores. CPU Mark: 10231 Single Thread Performance: 2287

Does it make sense to build a server specifically to gain the best Single Thread performance for an application like this? Are there any cons I need to worry about? Would a newer OS make a big difference?

The current host server has the following specs: Proliant DL380 G7 2 Physical CPU's : Intel(R) Xeon(R) X5675 @ 3.07 GHz 6 Cores Each for 24 logical processors (vCPU) total Hyperthreading is enabled. 144 GB of RAM

Storage is on a newer SAN and I am sure that is not playing a part in our performance issues.

The business system VM is configured with 2 vCPU's and 24 GB of RAM. The OS is Windows Server 2008 R2. The business system software is optimized to run on 4 - 6 GB of RAM in the app pool in IIS. I have never seen the VM go above 16 GB in use.

We are also running 3 other VM's on the host. One is really doing very little right now and will likely be turned off in the very near future. It has 2 vCPU and 8 GB of RAM.

The 2nd is running our MS Sql database. That one has 8 vCPU and 64 GB of RAM. We had a DBA look at it and he does not feel that it is the cause of our issues, at least not from the database performance side.

The 3rd VM is running our public website. It averages less than 25 percent on CPU. It has 3 vCPU and 16 GB of RAM.

Once again, any help or wisdom you can provide would be awesome and much appreciated.

Thanks!

Answer 1

You are correct in your assumptions. For your particular case stacking Mhz's instead of vCores is a right way to go. Take a look at this processor: (features 4x 3,5-3,7 Ghz physical cores + HT).

However, I cannot see the real issue from what you have described unless you can provide your actual "CPU Ready" value.

Answer 2

Couple of things;

1) Try to limit yourself to as many vCPUs that your VM actually needs. This has to do with the resource scheduler in VMware ESXi, if you have a VM with 8 vCPUs, it has to find a timeslot on a physical CPU that has 8 cores free at the given time to run the clock cycle of the VM. So if you have 6 cores per CPU, the scheduler has to find a timeslot on both pCPUs, which basically puts everything else on hold. VMs does not run continiusly as physical machines do, they are "frozen" in between clock cycles, and if the scheduler has problems keeping up your VMs will spend more and more time "frozen". If you aren't running a huge database on the SQL VM, try lowering it's vCPUs to 6 and see if that doesn't improve things. I usually run 1 vCPU per default, 2 for larger VMs, and up to 4 for some larger databases. I've never seen a need to add more.

2) Forget about HyperThreading in VMware, it gives you a little more performance, around 10% according to some tests by VMware, so leave it on, but don't count on having 2x times the performance when specing hardware.

3) CPUs with faster clock rates give you faster single thread performance, but fewer cores gives you less ability to run more VMs. There's a reason VMware shows you an aggregate of all the speed of all the cores on the host, that's basically how ESXi sees CPUs, as an aggregate pool of compute power.