How a Simple VMware Misconfiguration Cost Our Client Months of Performance Issues

TLDR: A warehouse management system was running slow because VMware presented 16 cores as 16 sockets × 1 core. SQL Server Standard Edition’s compute-capacity limit (socket/core caps) meant only 4 cores were usable. Reconfiguring the VM to fewer sockets with more cores each restored full CPU access. No hardware changes, no licensing changes - just a VM setting.

The Setup

A client came to us frustrated. Their SQL Server was painfully slow. They’d tried everything:

• Months of troubleshooting
• Consultations about hardware upgrades
• Endless finger-pointing at “slow applications”

Nothing worked.

Then we ran our 110-Point SQL Server Health Check.

One of the first things we checked: how many CPUs was SQL Server actually using? The answer was 4 – on a VM allocated 16.

Why This Happens

VMware lets you configure CPU allocation two ways:

Both configurations give you 16 total vCPUs. Windows and most monitoring tools report 16 processors either way.

But SQL Server Standard Edition enforces compute limits based on how the OS presents the CPU topology. Standard Edition is limited to the lesser of 4 sockets or 32 cores (24 cores on SQL Server 2022 and earlier). When VMware presents 16 sockets with 1 core each, the OS reports 16 sockets – and SQL Server caps itself at 4.

The result: a 16-core VM running SQL Server on 4 cores.

This isn’t a bug. It’s how SQL Server Standard Edition compute limits intersect with virtualization topology. SQL Server even logs the CPU count at startup in the error log – but if you’re not looking for it, it’s easy to miss.

How to Check Your Environment

Step 1: Query SQL Server’s visible CPU count

SELECT cpu_count FROM sys.dm_os_sys_info

This returns the number of logical processors SQL Server is currently allowed to use. If this number is lower than your VM’s allocated vCPUs, you may have a configuration mismatch (such as CPU topology, edition limits, affinity settings, or licensing constraints).

You can also check the SQL Server error log at startup – it logs how many CPUs it detects.

Step 2: Check VMware CPU configuration

In vSphere Client:

1. Right-click your VM → Edit Settings
2. Expand CPU
3. Check two values:
   • Number of CPUs (total vCPUs)
   • Cores per Socket

If you see 16 CPUs with 1 core per socket, that’s 16 sockets. SQL Server Standard will cap at 4.

Recommended configuration: Minimize socket count, maximize cores per socket. For 16 cores on SQL Server Standard: 1 socket × 16 cores (simplest NUMA), 2 sockets × 8 cores, or 4 sockets × 4 cores all work. Avoid configurations where sockets exceed your edition's limit.

Related: How Many CPUs Is Your SQL Server Actually Using?

The Fix

Changing the VM’s CPU topology requires a VM restart and verification that SQL Server licensing, NUMA configuration, and CPU affinity settings remain appropriate. After reconfiguring, SQL Server immediately reported all 16 available cores. Performance improved proportionally.

The client avoided a hardware upgrade that was already being scoped.

The Lesson

This issue was discoverable on day one with a single query. It’s in the error log at every SQL Server restart. The information was always there.

But when you’re deep in query tuning and execution plans, it’s easy to overlook the fundamentals. That’s why we never skip a health check before performance work.

Our 110-Point SQL Server Health Check covers:

• Virtualization misconfigurations
• Licensing and edition limitation conflicts
• Hidden resource bottlenecks
• Settings that silently degrade performance

Performance tuning without a proper baseline is guesswork. The basics matter – we just take them seriously.