Picking how many virtual sockets vs cores per socket in ESXi

Picking how many virtual sockets vs cores per socket in ESXi

So I'm looking at the options for allocating resources to my vm and I come across an interesting breakdown of my cpu within vmware.

So we see the possibilities and combinations for my small 2 x xeon e5503 which have 2cores each and no HT(hyperthreading)  But the question comes up what's better. If I max out vsocket or vcores, or a combination of them?

With these settings I load up my vm and go looking at what's going on at Task manager.

So we can see that I have 1 socket and 2 virtual processors, Which is what I expected based on my settings.  I'm not sure why the cpu graph isn't broken down into 2 different blocks showing the 2 cores however...  Checking the vm though I found the cpu was pegged at 50% cpu usage nonstop with Windows Module Installer clogging up my vm.  

• I had to do a bit of research, but I expected it to be related to Microsoft's OS problem of Windows Update getting locked into a loop and just destroying your cpu until its resolved or you finally google what's going on yourself.  I'll be doing a blog post shortly on that and the few steps I took. but if you google/youtube it it's a pretty common error about TIworker.exe and windows update services.

So above you see it peaking around 50%  which is what you expect for processes/program that don't handle multithreading and the importance of higher clock cpus not just having a server with as many cores as you can.  It would go above 50% if I had multiple things going on at the same time, but in general that single 2.0GHz processor is the workhouse.

But the question remains...If I had good cpus what would be the best mix of sockets and cores.  I came across these postings

• http://frankdenneman.nl/2013/09/18/vcpu-configuration-performance-impact-between-virtual-sockets-and-virtual-cores/#comment-20293
• https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005362
• https://sqlperformance.com/2017/03/system-configuration/hardware-sql-server-2016-standard-edition

So going off these posts we see something extremely important from a licensing/OS perspective. Different operating systems can have hard caps for how many sockets they're going to use but not how many cores.  

"In vSphere a vCPU is presented to the operating system as a single core cpu in a single socket, this limits the number of vCPUs that can be operating system."- DENNEMAN

Denneman's article goes on to say it doesn't really matter the combination as long as you're not reaching any hard limits set by your Operating System. I think this changes in Windows Server 2012/SqlServer 2012 and they start going off cores...which is pretty much why noone wants to upgrade from Win2k8 r2 or Sql2008R2. Licensing becomes more complicated, and in general expensive.

Continuing reading on the article below shows an example of what happens when You've assigned things past the cap and the OS ignores the settings it can't handle.

• https://communities.vmware.com/thread/459934?start=0&tstart=0   which had this gem right at the bottom from ronsexton

Testing has shown i am better off in my case respecting the physical server configuration.
Most common host config is probably like ours, half height blade. 2 sockets , some cores. In this case 12 cores. 512GB of memory and Intel processors (v2)
Test was restoring a 300GB database with Microsoft SQL Server 2008 R2 on Windows Server 2012 R2 (both enterprise editions). 112GB of memory.

• Test 1, time to restore was 1 hour 12 minutes. Throughput was 52 MB/sec . Config was 12 sockets 1 core. This was bad!
• Test 2, time to restore was 9 minutes 50 seconds. Throughput was 334 MB/sec . Config was 1 socket 12 cores. This was great. Over 600% I/O performance improvement and a great time reduction.
• Test 3, time to restore was 9 minutes 59 seconds. Throughput was 330 MB/sec. Config was 2 sockets and 6 cores. Still great.

Only change as was the socket and core configuration. VM was of course brought down for each configuration change.
So not configuring the socket count on the VM higher than the physical host in this case resulted in a fantastic performance improvement.
Run your own load tests with your application to determine the best configuration for you.

TL/DR,  Check your OS/Software products for hard caps on vsockets, and check your licensing for softcaps on cores per socket to determine the best mix of the 2 for your vm.