The percentage of time that the virtual machine was ready to use CPU resources, but could not get scheduled to run on the physical CPU. This value is the average across all CPUs.

If this metric is high, check the Host CPU Usage:

• If Host CPU Usage is normal, the VM could have under-allocated CPU resources.

  If the VM has been configured with a CPU limit, consider raising or removing the limit. Or use resource controls to give higher priority to this VM, which will allocate more CPU resources to it.

• If Host CPU Usage is high, this could indicate a host over-commitment of CPU resources. Consider:

  • Reducing the number of VMs running on the host.

  • Increasing the available CPU resources by adding the host to a DRS cluster.

  • Increasing the efficiency with which VMs use CPU resources by tuning SQL statements and non-database applications.

  • Using resource controls to direct available resources to critical VMs.

Actively used CPU as a percentage of the total available virtual CPU in the virtual machine. Note that this is the host's view of the CPU usage, not the guest O/S view, so the values may differ.

If this value is high, check the VM CPU Ready Time:

• If VM CPU Ready Time is also high, the host has under-allocated CPU resources to the VM. (See VM CPU Ready Time below.)

• If VM CPU Ready Time is not high and you are not experiencing a performance problem, high CPU usage values are not a cause for concern.

• If VM CPU Ready Time is not high but you are experiencing a performance problem, you can address the issue in either of the following ways:

  • Increase the CPU resources provided to the VM.

    To do this, you can add vCPUs to the VM, migrate the VM to a host with more powerful processors, or add additional VMs running the same application and then balance the workload.

  • Increase the efficiency with which the VM uses CPU resources.

    To do this, you can tune the queries with long Memory/CPU wait types or tune the non-database applications using the most CPU.

The amount of wait time incurred because the VM in which the database is running has to wait on physical CPU resources allocated to other VMs.

If the database instance is on a VM configured to use multiple vCPUs, co-stop delays can cause long Memory/CPU wait times. Co-stop delays occur when a VM is not being scheduled to run consistently because it has to wait on vCPU resources to be freed from other VMs contending for those vCPUs.

If this value is not near 0, consider taking one of the following actions to reduce co-stop delays:

• Decrease the number of vCPUs on the VM.
• Add additional CPUs to the pool available to the VMs.
• Use vMotion to migrate other VMs to a different host to reduce contention.

The average rate at which data is read from each LUN on the host.

read rate = # blocks read per second x block size

If your database instance is suffering from disk I/O performance related issues, it's possible that another VM on the same host is consuming high amounts of disk resources and causing delays for this VM. To understand that relationship, check the Physical I/O rate from the database instance compared to this metric. If this metric is much higher than the database metric, another VM might be causing the issue. If not, this VM might be putting to many demands on the underlying disk devices.

The average rate at which data is written to each LUN on the host.

write rate = # blocks written per second x block size

The number of disk bus reset commands issued. This typically occurs when storage demand is excessively high, or when storage is not properly configured to handle the I/O load.

Bus Resets occur when the disk subsystem times out and commands are canceled and retried. This happens when the HBA device is overloaded or its queue depth is exhausted.

The number of disk commands that were aborted. This typically occurs when storage demand is excessively high, or when storage is not properly configured to handle the I/O load.

Beyond re-balancing load, there is typically little that can be done from within vSphere to solve problems related to slow or overloaded storage. Follow the guidelines from your storage vendor to monitor the demand being placed on the storage device, and follow the vendor-specific configuration recommendations to configure the device for the demand. If the device is not capable of satisfying the I/O demand with good performance, distribute the load among multiple devices, or obtain faster storage.

The average rate at which data is read from each virtual disk on the virtual machine.

read rate = # blocks read per second x block size

The average time taken to process a SCSI read command issued from the Guest OS to the virtual machine (across all VMs).

Expected disk latencies depend on the nature of the storage workload (for example, read/write mix, randomness, and I/O size) and the capabilities of the storage subsystems.

The average rate at which data is read from a specific LUN on the host (across all VMs on the host).

The actual memory usage on the host (total consumed memory / total machine memory). High host memory usage is not necessarily a problem, but could indicate host memory over-commitment (or looming over-commitment). Check to see if memory swapping is occurring by looking at memory swap in/out rates, which is a clear indicator of host memory over-commitment.

Memory that is actively in use (that is, used currently or in the recent past) as a percentage of virtual machine configured memory.

While a VM may have been allocated large amounts of memory, it is possible that the OS and applications are only using a small percentage of what the VM was assigned. Inactive memory is subject to being "ballooned" (reclaimed by other VMs) when memory is scarce.

When the active memory for all VMs exceeds the total host memory, it indicates host memory saturation. As a result, host-level memory swapping typically occurs.

The amount of memory used to run the virtual machine. Configuring a virtual machine with excess memory or excess virtual CPUs will unnecessarily increase the overhead.

The rate at which memory is swapped in from disk. A value greater than 0 indicates that performance is suffering due to lack of memory. This is typically caused by memory being previously swapped out, memory over-commitment (many virtual machines with high amounts of active memory), or a problem with the balloon driver. Consider the following possible solutions:

• Reduce the level of memory over-commit.
• Enable the balloon driver in all VMs.
• Reduce memory reservations.
• Use resource controls to dedicate memory to critical VMs.

The number of dropped transmitted packets across all physical NICs on the host. The following problems can cause the guest OS to fail to retrieve packets quickly enough from the virtual NIC:

• High CPU utilization
• Guest OS driver configuration

Solutions are all related to ways of improving the ability of the guest OS to quickly retrieve packets from the virtual NIC. You can:

• Increase the CPU resources provided to the VM.
• Increase the efficiency with which the VM uses CPU resources.
• Tune network stack in the Guest OS.
• Add additional virtual NICs to the VM and spread network load across them.