Response Time

This shows the full round-trip response time (in milliseconds) of a query representative of general workload (select 1, by default). If required, you can change the query used to determine response time. Use a Spotlight Client to Configure | SQL Server Response Time.

Virtualization Overhead

In a virtual environment the physical CPU of a host is shared by virtual machines and the hypervisor. Multiple processes may want to use the physical CPU of the host at the same time. The virtual machines may have to wait to be scheduled on a CPU.

Gauge

Show the percentage of CPU that is unavailable to this virtual machine because it is being consumed either by other virtual machines or by VMware itself. The amount of ready time is shown as a percentage of the theoretical maximum CPU available to the virtual machine.

Applicable to Windows Servers hosted on VMWare.

Wait Time in nanoseconds

Show the average time the virtual machine spent waiting for CPU over the collection interval (average 5 minutes). The average queue time should remain under 60,000ns. If the average queue time exceeds 60,000ns then a Hyper-V CPU wait time per dispatch alarm is raised. A high alarm is raised if the average queue time exceeds 100,000ns. See also the Windows Server connection | CPU drilldown.

The Hyper-V - Virtual Overhead alarm is raised on excessive CPU being used by the hypervisor on this virtual machine.

Applicable to Windows Servers hosted on Hyper-V.

Not Virtualized

The Windows Server is not hosted on a virtual machine or the virtual machine is unknown. Update the Windows Server connection details from the Spotlight Client, Configure | Connections.

How is a performance health rating calculated?

A database with healthy performance spends its time productively - on CPU and I/O.

A database with unhealthy performance often spends too much time waiting for bottlenecks such as locks and latches.

By analyzing the waits of a SQL Server instance Spotlight can determine the relative proportion of time the instance spends on CPU, I/O, locks and latches. As long as a database instance devotes enough time to CPU and I/O, it will be considered healthy.

Additionally, the single-block-read latency of the database instance is taken into consideration. This needs to be low/fast enough to indicate that the time being spent on I/O is productive.

However, if the time spent on waits is significantly lower than the available CPU time on the Windows host, there is not enough load being placed on the database instance to assess its health.

In summary: if a database instance devotes most of its time to CPU and I/O and has a low single-block read latency, it will obtain a performance-health rating of 80% or more, which is considered healthy.