6

We have a ESX host:

It has 2 CPU x 8 cores each, and HT enabled. So, total 16 physical cores or 32 logical cores.

It has a single dedicated SQL VM on it (no other VMs run on this host), and it has 16 vCPUs assigned:

and the SQL NUMA config looks like:

Does it mean these 16 vCPUs map to the 16 logical cores in 1 CPU, and that the other CPU containing 16 more logical cores is sitting idle?
Will increasing it to 32 vCPUs make a difference?

I found this article, that says do not assign more vCPUs than actual physical cores, regardless of logical cores. Why not?

techraf
  • 4,163
  • 8
  • 27
  • 44
d-_-b
  • 191
  • 2
  • 7
  • 1
    That article doesn't say why, but it did give a link to another article that does say why. Did you read it? – Michael Hampton Nov 03 '16 at 16:52
  • Just read [that](http://wahlnetwork.com/2013/09/30/hyper-threading-gotcha-virtual-machine-vcpu-sizing/). Yep it explains why - it's better to assign a physical core than a HT core, so 16 vCPUs would be scheduled as 8 on CPU1 and 8 on CPU2, rather than all 16 on CPU1 – d-_-b Nov 03 '16 at 16:57
  • @MichaelHampton, but wait.. that is only if they ALL require 100% CPU, but if they don't, then having 32 vCPUs would take advantage of idle CPU cycles, no ? – d-_-b Nov 03 '16 at 17:05
  • 1
    I'm pretty sure this is peculiar to ESXi. And possibly to older versions of ESXi. Other hypervisors may not have this sort of restriction. For instance, KVM is perfectly capable of presenting a hyperthreaded virtual CPU, or almost any arbitrary virtual CPU topology, to a guest and has no such restriction or performance problem when the host has hyperthreaded CPUs. – Michael Hampton Nov 04 '16 at 01:28
  • Are you running Standard Edition or Enterprise Edition of SQL Server? Or just a simple Development Edition? Which version of SQL Server? 2012, 2014, 2016? https://www.vmguru.com/wordpress/wp-content/uploads/2015/03/SQL_Server_2014_key_capacity_limits.png – John K. N. Nov 04 '16 at 12:46
  • Enterprise, 2012.. we have SA with M$ and lot of cores paid for, so licensing money not an issue – d-_-b Nov 04 '16 at 23:40
  • Supposedly the vNUMA 1 core per socket default is because there is a penalty for spanning a physical node with the virtual one. This example benchmark did something silly like 12 vCPUs per socket with 6 core nodes. https://blogs.vmware.com/vsphere/2013/10/does-corespersocket-affect-performance.html – John Mahowald Nov 06 '16 at 00:16
  • I like to think that HT gives the hypervisor threads to run itself in some few percent spare processor resources. No data to back that up though. – John Mahowald Nov 06 '16 at 00:24
  • How much RAM does the server have ? – Overmind Jan 15 '19 at 13:54

3 Answers3

1

Generally, keeping assigned vCPUs no more than the physical cores (ignoring HT) is playing it safe. You have 2 physical CPUs with 8 core each (although I remember the E5-2667 having 6) - that means 16 true cores. No need to assign more. Note that in many situations like your it's more likely to run out of RAM rather than CPU power.

Overmind
  • 2,970
  • 2
  • 15
  • 24
0

The reason they don't recommend that is because how HyperThreading works in VMware, it's not twice the compute power, more like 10% extra according to some tests. So you shouldn't define any more vCPUs than physical cores. If that huge VM isn't alone on that host, you might also like to keep in mind that while that VMs clock cycles are running not much else is going to happen on the other VMs, as that single VM consumes all available cores, and it won't run if not all 16 cores are available.

Stuggi
  • 3,366
  • 4
  • 17
  • 34
0

MSSQL is a processor hog, and for good reason. It would also reduce the effectiveness of HT because HT only splits the load of the processor but doesn't double your compute. If you're going to have a high performance SQL server running, you may want to consider assigning core-affinity rules in vSphere and prevent other VMs from running against those cores. I know it defeats the purpose of virtualization, but there are still some advantages.

Jarrod L. J. Gibson
  • 531
  • 3
  • 18