The CPU panel tracks the performance of the processor used by your monitored SQL Server. Unexpected spikes in CPU usage and call rates may warn you about the beginning of a serious performance issue. Chronically high CPU metrics may indicate the need for server maintenance, query tuning, or index updates to better handle the ongoing workload. For additional information, see how to get your CPU performance details.
Usage chart
The CPU Usage chart displays the percentage of processing power in use on the computer that hosts the SQL Server instance over a period of time. The CPU view on the Resources view allows you to track your CPU usage over a period of time, along with other key CPU statistics. For additional information about how SQL Diagnostic Manager works with virtual machines and collects metrics, see How SQL Diagnostic Manager works with a virtual environment.
Metric | Why it is important |
|---|---|
A higher SQL usage can indicate that SQL Server is spending too much time processing queries. | |
Total usage | A high total CPU usage can indicate that this server does not have enough resources to adequately process its current workload. |
A high virtual machine usage can indicate that the processor power allocated to this VM is insufficient for its current workload. | |
Host usage | A high host server usage indicates the processing power on this host is insufficient to handle the workload of the currently active VMs. |
Processor Queue Length gauge
The CPU Processor Queue Length gauge displays the current value of the processor queue length metric. Use this metric to determine how much work is waiting on this server. A high processor queue could indicate a blocking session or other performance issues.
Call Rates chart
The CPU Call Rates chart breaks down the processor workload into the number of batches, compilations, and transactions completed each second, giving you a detailed view of which activities are resource-intensive.
Metric | Why it is important |
|---|---|
A high throughput rate can indicate a higher risk of network, CPU, and resource issues as the SQL Server performance degrades. | |
A high number of compilations (greater than 100 per second) can indicate a high server workload or that there is more recompilation overhead than necessary. | |
A high re-compilation rate can indicate excessive re-compilation overhead. | |
A high rate of transactions can indicate a higher risk of resource issues, such as blocks or locks, due to the heavier workload. |
Differences in statistics
You may notice some difference in your statistics, such as your OS CPU usage being higher than your VM CPU usage. While the hypervisor manages resources efficiently, the demand for physical resources may be greater than what it has to provide. For example, a guest OS on a virtual machine submits a batch of work to a CPU for execution. However, all of the physical CPUs are committed to other work, so there is no physical CPU available on the host to process the work. In this situation, the VM has to wait for a CPU to become available to process its work. While it is waiting, the guest OS is unaware of the wait and assumes that it is simply taking longer for the CPU to process this batch of work, and the OS thinks it is using more CPU power than it is actually using.
Remember that SQL Diagnostic Manager uses the additional overhead of the hypervisor to calculate the VM metrics. In this situation, the hypervisor knows the VM is just waiting for a CPU, so it does not charge the VM for CPU processing power while it is waiting. The result is that the guest OS reports that it is using the additional processing power.
Available alerts
- Host CPU Usage (Percent) Alert
- OS Processor Time (Percent) Alert
- OS Processor Queue Length (Count) Alert
- SQL Server CPU Usage (Percent) Alert
- VM CPU Usage (Percent) Alert