I am now starting look at our VM estate rather than just let it run and hope for the best!!
I was looking at the metrics from ESXTOP and see some of the suggested values like 10 for %RDY, I had a quick question on the scale that ESXTOP is displaying the numbers in.
I am currently looking on one of our hosts at the VM's and see that the %RDY stats range from 0.13 up to 0.62
I wasn't sure If 0.13 is below 1% or if that is actually 13% what's the scale?, as from my reading based on a single vCPU one is good the other bad.
I was expecting the below but now i'm not so sure.
1.00 = 1%
13.00 = 13%
Four virtual machine CPU performance metrics can be used together to gain insight into the responsiveness of a virtual machine or its Guest OS:
These performance metrics can be reviewed using the Performance tab in the vSphere Client or using the esxtop or resxtop command-line utilities. Chose the most appropriate method for your environment.
For more information on using custom performance charts, see the Customizing Chart Views section of the Resource Management Guide or the View Advanced Performance Charts section of the vSphere Monitoring and Performance Guide.
For more information on using
resxtop, see the Performance Monitoring Utilities: resxtop and esxtop section of the vSphere Monitoring and Performance Guide or Resource Management Guide.
resxtop --server HostNameOrIPAddress [--username root]
ID GID NAME NWLD %USED %RUN %SYS %WAIT %RDY %IDLE %OVRLP %CSTP %MLMTD %SWPWT
186 186 VMName 4 2.11 2.08 0.00 397.64 0.25 197.71 0.20 0.00 0.00 0.00
This value represents the percentage of absolute time the virtual machine was running on the system.
%RUNmay indicate that the guest operating system is busy conducting an operation.
%RUNis near zero and the virtual machine is unresponsive, it could mean that the virtual machine is idle, blocked on an operation, or is not scheduled due to resource contention. Look at other values (
%CSTP) to identify resource contention.
%RUNis near the value of the number of
vCPUS x 100%, it means that all vCPUs in the virtual machine are busy. This is an indicator that the guest operating system may be stuck in a operational loop. To investigate this issue further, you may need to engage the appropriate operating system vendor for assistance in identifying why the guest operating system is using all of the CPU resources.
%WAITvalue is proportionally higher than
%CSTP, then it could indicate that the world is waiting for a VMkernel operation to complete.
%SYSis proportionally higher than
%SYSrepresents the percentage of time spent by system services on behalf of the virtual machine.
%WAITvalue can be a result of a poorly performing storage device where the virtual machine is residing. If you are experiencing storage latency and timeouts, it may trigger these types of symptoms across multiple virtual machines residing in the same LUN, volume, or array depending on the scale of the storage performance issue.
%WAITvalue can also be triggered by latency to any device in the virtual machine configuration. This can include but is not limited to serial pass-through devices, parallel pass-through parallel , and USB devices. If the device suddenly stops functioning or responding, it could result in these symptoms. A common cause for a high
%WAITvalue is ISO files that have been left mounted in the virtual machine accidentally that have been deleted or moved to an alternate location. For more information, see Deleting a datastore from the Datastore inventory results in the error: device or resource busy (101....
Max-Limited, %MLMTDvalue. This represents the amount of time that the virtual machine was ready to execute, but has not been scheduled for CPU time because the VMkernel deliberately constrained it. For more information, see the Managing Resource Pools section of the vSphere Monitoring and Performance Guide or Resource Management Guide.
%MLMTDis low it may indicate that the ESX host has limited CPU time to schedule for this virtual machine.
%CTSPis proportionally high compared to
%RUN, it may indicate that the ESX host has limited CPU resources simultaneously co-schedule all vCPUs in this virtual machine.