VM metrics collected by DPA
The following sections list the metrics that DPA collects from virtual machines (VMs). For database instances that run on a VM, these metrics are displayed in addition to the metrics collected for the database type.
- Learn how to view these metrics and change the thresholds.
- For detailed information about resolving issues, click the next to the metric on the Resources tab. The Information link is not available for all metrics.
- If the database instance runs on a virtual machine (VM), metrics collected for the VM are described in VM metrics collected by DPA
|VM CPU Usage Percentage||
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:
|VM CPU Ready Time||
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:
|Host CPU Usage||Actively used CPU as a percentage of the total available CPU on the machine. If this metric is high, determine if the VM CPU Ready Time is also high.|
|VM CPU Usage MHz||The average amount of CPU (in MHz) actively used by the VM (for all vCPUs configured for the VM). This is the host's view of the CPU usage, not the guest operating system view, so the values may differ. Typically the host view of CPU is more accurate.|
|VM Total CPU Usage Time||
The total amount of time (in milliseconds) that the VM spent using the virtual CPUs (that is, the sum of time spent on each virtual CPU during the time period).
|VM Total Co-Stop Time||
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:
|VM Co-Stop||The percentage of time the VM has been waiting on physical CPU resources allocated to other VMs. If this value is above 3%, consider the actions listed above to reduce co-stop delays.|
|VM Active Memory Usage||
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.
|VM Memory Granted||Memory that has been given to the virtual machine by the host, not including overhead. Typically, VMs are granted increasing amounts of memory over time until reaching the configured VM memory size.|
|VM Memory Swap In Rate||
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:
|VM Memory Swap Out Rate||The rate at which memory is swapped out to disk. High values indicate a problem with lack of memory that is causing performance to suffer. This is typically caused by either memory over-commitment (many virtual machines with high amounts of active memory) or a problem with the balloon driver.|
|Host Memory Usage||
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.
|VM Memory Balloon Size||The amount of virtual machine memory that is currently claimed by the balloon driver. If high amounts of ballooning are occurring, check for high Memory Swap In/Out Rates which would indicate performance problems.|
|VM Memory Balloon||The percentage of the virtual machine memory that is currently claimed by the balloon driver. This is not necissarily a performance problem, but shows the host starting to take memory from VMs that need less memory and assigning it to VMs with large amounts of active memory. If high amounts of ballooning are occurring, check for high Memory Swap In/Out Rates which would indicate performance problems.|
|VM Memory Overhead||
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.
|VM Disk Commands||The number of disk commands issued by the virtual machine. High disk usage could be due to guest swapping, which you can investigate using OS analysis tools. VMs configured with insufficient memory can also cause excessive guest swapping and, in turn, high disk usage.|
|VM Disk Commands Aborted||
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.
|VM Disk Bus Resets||
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.
|VM Disk Read Rate||
The average rate at which data is read from each virtual disk on the virtual machine.
|VM Disk Write Rate||
The average rate at which data is written to each virtual disk on the virtual machine.
|VM Disk Usage Rate||The average disk I/O rate across all virtual disks on the virtual machine.|
|Host Max Total Disk Latency||The highest latency value across all disks used by the host. Latency measures the time taken to process a disk command issued by the guest OS to the virtual machine. High latency is a key indicator of slow storage.|
|Host Disk Read Rate||
The average rate at which data is read from each LUN on the host.
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.
|Host Disk Write Rate||
The average rate at which data is written to each LUN on the host.
|Host Disk Device Read Rate||
The average rate at which data is read from a specific LUN on the host (across all VMs on the host).
|Host Disk Device Write Rate||The average rate at which data is written to a specific LUN on the host (across all VMs on the host).|
|Host Disk Device Read Latency||
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.
|Host Disk Device Write Latency||The average time taken to process a SCSI write command issued from the Guest OS to the virtual machine (across all VMs).|
|VM Data Receive Rate||The average rate at which data is received on the virtual machine. This represents the receive bandwidth of the network.|
|VM Data Transmit Rate||The average rate at which data is transmitted on the virtual machine. This represents the transmit bandwidth of the network.|
|VM Network Packets Received||The number of packets received across all vNICs on the virtual machine.|
|VM Network Packets Transmitted||The number of packets transmitted across all vNICs on the virtual machine.|
|Host Dropped Received Packets||The number of dropped received packets across all physical NICs on the host.|
|Host Dropped Transmitted Packets||
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:
Solutions are all related to ways of improving the ability of the guest OS to quickly retrieve packets from the virtual NIC. You can: