A client’s SQL Server silently ran on 4 of its 16 cores for months, because VMware presented the vCPUs as 16 single-core sockets and Standard Edition caps at 4 sockets. A free VM setting reclaimed the other 12 cores and killed the hardware upgrade they’d already scoped.
- Standard Edition caps at the lesser of 4 sockets or 32 cores (24 cores on SQL Server 2022 and earlier). 16 sockets of 1 core each hits the socket cap at 4. Windows still reports all 16, so it hides easily.
- Run
SELECT cpu_count FROM sys.dm_os_sys_info. If it’s below your allocated vCPUs, you have a topology mismatch. SQL Server also logs the count at every startup. - Reconfigure for fewer sockets and more cores each (for 16 cores: 1 socket of 16, or 2 of 8, or 4 of 4). It needs a restart, then check NUMA and CPU affinity are still sane.
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:
| Configuration | Sockets | Cores per Socket | Total Cores |
|---|---|---|---|
| What they had | 16 | 1 | 16 |
| What they needed | 4 | 4 | 16 |
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_infoThis 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:
- Right-click your VM → Edit Settings
- Expand CPU
- 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.
Speak with a SQL Expert
In just 30 minutes, we will show you how we can eliminate your SQL Server headaches and provide operational peace of mind
