SQL Server and CPU Hyper-Threading in Virtual Environments


I recommend leaving the hyper-threaded logical cores enabled in the host BIOS, but not depending on them for performance gains. Hyperthreaded CPU cores, or logical cores, should not be factored into CPU overcommitment rations as if they are full processor cores.

Every task that is triggered inside a virtual machine must be scheduled to run on a physical compute resource. These scheduled tasks must be placed into a scheduling queue inside the hypervisor layer before it gets its time on the physical compute resource. If the hypervisor is overloaded, or if the vCPU scheduling queues are imbalanced from an incorrect vCPU configuration, these queues can grow, and the performance impact on the vCPU performance can suffer.

The use of a hyperthreaded core for a VM workload is quite interesting. Think of a hyperthreaded core as follows. If the physical core utilization is represented as below, the percentage of the core’s maximum processing cycles that are not being utilized are presented to the host hardware as a second (logical) core.

Certain code sent to the CPUs from an operating system is largely single threaded in nature, meaning that only so many actions can occur with each clock cycle. If certain items are being blocked or waiting for other system resources, that part of the CPU execution is idle for those clock cycles, and the hyperthreading process allows for these actions to flip back and forth to make better utilization of the CPU efficiency.

This architecture represents a CPU socket populated with a single CPU containing four physical CPU cores with hyperthreading enabled.

The physical representation, as seen by an operating system directly presented to the hardware, is as follows.

The OS now ‘sees’ that it contains one CPU socket populated with a CPU package, with eight physical and sixteen logical CPU cores presented. The remainder of each physical core became a second logical core. Underneath, it is the same processing component that is executing the tasks.

Most workloads do not consume nearly all of each physical core, especially while handling other system and resource wait states, so the workload is able to context switch appropriately and balance the competing workloads to adequately utilize more of the physical core but without imposing a significant performance penalty to the workload.

However, if a given CPU workload is consuming a very significant amount of CPU cycles per physical core, the remaining CPU cycles available to a hyperthreaded core are much smaller.

If the same workload is equally distributed amongst all eight logical cores, the available clock cycles are much smaller for the HT cores. If equally distributed, the workload would potentially slow down due to the context switching imposed on the individual physical core to accommodate the additional load.

Now, add virtualization into the architecture. In this case, VMware is very aware of hyperthreading and actively works to focus the CPU workload specifically on the physical cores.

The CPU consumption coming from the guest workload can be quite high on some of the busiest SQL Server instances, which can provide a significant amount of CPU scheduling pressure on the physical CPU cores, both from a raw workload perspective, and from a context switching perspective. The hypervisor also will feel the stress of active CPU workload scheduling. This pressure can only be relieved within the hypervisor effectively halting some of the execution paths to streamline the commands and results from the processing components.

Therefore, understand that hyperthreaded cores are not to be treated as regular cores, but can help the underlying performance as the hypervisor takes advantage of them as needed. Leave hyperthreading enabled.

Original post (opens in new tab)
View comments in original post (opens in new tab)