ESXTOP
voici une explication des compteurs CPU du module ESXTOP (en ligne de commande dans le Service Console) :
* En haut :
PCPU(%) est l’utilisation des processeurs physique (socket)
LCPU(%) est l’utilisation des processeurs logiques (socket x cœur x HT)
CCPU(%) est l’utilisation processeur du service console (détail dans TOP), si ce compteur est chargé ca peut venir d’un outil tiers dans les Service Console (ex : Backup)
* Dans le milieu :
%USED de la ligne « idle » indique la somme des processeurs non-utilisé. La valeur maximum est le nombre des CPU x 100%. Si ce compteur est à < 100% le système est très chargé
Les lignes du bas indique les VMs, le %USED représente la charge CPU de chaque VM. La valeur max est de vCPU de la VM x 100%
Pour avoir le détail d’une VM, appuyer sur « e » et indiquer l’ID de la VM. On a alors l’ensemble des Worlds qui la compose :
vmmX : pour chaque vCPU de la VM (X étant le n° du vCPU), ce World représente l’ensemble de l’exécution & virtualisation d’une VM (OS, Application, Hyperviseur)
vcpu-X : chaque World est assigné à un vmmX, il représente la partie virtualisation des périphériques IO
mks : représente la partie Mouse/Keyboard/Screen
vmware-vmx : ce World assure la communication avec les autres Worlds (2 VMX Worlds en ESX3, 1 seul en ESX4) principale pour l’ordonnancement des vCPU par l’Hyperviseur
* Le détail des colonnes :
%USED = %RUN + %SYS – %OVRLP
%USED représente la charge CPU total de chaque VM
%SYS représente le % de temps passé par les services systèmes (interrupt handlers, bottom halves & system worlds). Si ce compteur est élevé, ca veut dire qu’il y a une grosse charge IO dans la VM.
%OVRLP représente le % de temps passé par des services systèmes des autres Worlds de la VM. Si ce compteur est élevé, ca veut dire que l’ESX es chargé en IO
%RUN représente le % de temps passé pour l’exécution d’une VM
%RUN + %RDY + %CSTP + %WAIT = 100%
%RDY représente la proportion de temps que la VM est prête à être exécuté. C’est-à-dire le temps qu’une VM attend pour exécuter une instruction CPU. Si ce compteur moins les limites CPU (%RDY – %MLMTD) est > à 20% ca veut dire qu’il y a contention CPU sur l’ESX.
%MLMTD représente le % de temps qu’une VM est prête à être exécuté mais qu’elle est bloqué la limitation CPU (limitation de ressources d’un VM).
%CSTP représente le % de temps qu’une VM exécute des instructions vide. Ce valeur indique qu’une VM exécute des instructions UMP dans une VM SMP. Si cette valeur est souvent élevé, ca veut dire qu’elle est surdimensionné en vCPU par rapport au capacité de l’application.
%WAIT représente le % de temps qu’une VM passe en attente. La valeur de %WAIT – %IDLE permet d’estimer comme de temps les CPU passe a attendre des réponses IO. Seulement pour les Worlds vmmX, les autres Worlds sont normalement à ~100%.
%IDLE représente le % de temps qu’un vCPU est en « Idle Loop ». Cette valeur n’a d’importance que sur les CPU world, les autres Worlds sont à 0.
%SWPWT (seulement en ESX4) représente le % temps d’attente que le VMkernel swap la mémoire. Ce temps est inclus dans le %WAIT. Si la valeur est élevé, la VM est en train de swappé ca mémoire coté Hyperviseur.
CPU view
| CPU Load avarage for the last one, five and 15 minutes | |
| %USED | CPU Core cycles used by a VM. High values are an indicator for VMs causing performance problems on ESXi Hosts. |
| %SYS | Percentage of time spent by system to process interrupts and to perform other activities on behalf of the world. Possible caused by high I/O VM. !>20 |
| %VMWAIT | percentage of time a VM was waiting for some VMkernel activity to complete (such as I/O) before it can continue. Includes %SWPWT and « blocked », but not IDLE Time (as %WAIT does). Possible cause: Storage performance issue / latency to a device in the VM configuration eg. USB device, serial pass-through device or parallel pass-hrough device !100 |
| %RDY | Percentage of time a VM was waiting to be scheduled. If you note values between 5 and 10 percent take care. !>10 Possible reasons: too many vCPUs, too many vSMP or a CPU limit setting (check %MLMTD) |
| %CSTP | This value is interesting if you are using vSMP VMs. It shows the percentage of time a ready to run VM has spent in co-deschedule state. !>3 If value is > 3 decrease the number of vCPUs from the VM concerned. |
| %MLMTD | Counter showing percentage of time a ready to run vCPU was not scheduled because of a CPU limit setting. Remove the limit for better performance. !>1 |
| %SWPWT | Counter showing how long a VM has to wait for swapped pages read from disk. A reason for this could be memory overcommitment. Pay attention if %SWPWT is > 5. !>5 |
Memory view
| average memory overcommitment for the last one, five and 15 minutes | |
| Memory status: high enough free memory available soft <4% free memory: Host reclaim memory by ballon driver hard <2% free memory: Hosts starts to swap, you will see performance troubles low <1% free memory: ESX stop the VMs to allocate more RAM |
|
| MCTLSZ | Amount of guest physical memory (MB) the ESXi Host is reclaiming by ballon driver. A reason for this is memory avercommitment. !>1 |
| SWCUR | Memory (in MB) that has been swapped by VMKernel. Possible cause: memory overcommitment !>1 |
| SWR/s | Rate at which the ESXi Host is wrting to or reading from swapped memory. Possible cause: memory overcommitment !>1 |
| SWW/s | |
| CACHEUSD: Memory (in MB) compressed by ESXi Host !>1 | |
| ZIP/s | Values larger 0 indicate that the host is actively compressing memory. !>1 |
| UNZIP/s | Values larger 0 indicates that the host is accessing compressed memory. !>1 Reason for this behaviour is memory overcommitement. |
Memory (NUMA) view
| NMN | Numa Node where the VM is located |
| NRMEM | VM Memory (in MB) located at remote Node |
| NLMEM | VM Memory (in MB) located at local Node |
| N%L | Percentage of VM Memory located at the local NUMA Mode. If this value is less than 80 percent the VM will experience performance issue. !>80 |
Disk Adapter view
| DAVG | Latency at the device driver level. Indicator for storage performance troubles !>25 |
| KAVG | Latency caused by VMKernel. Possible cause: Queuing (wrong queue depth parameter or wrong failover policy) !>3 |
| GAVG | GAVG=DAVG+KAVG !>25 |
| ABRT/s | Commands aborted per second. If the storage system has not responded within 60 seconds VMs with an Windows OS will issue an abort. !>1 |
| Reset/s | Number of commands reset per second !>1 |
Network view
| %DRPTX | Dropped Packages transmitted/Dropped Packages received. Values larger 0 are a sign for high network utilization. !>1 |
| %DRPRX | |
| Used-by / Team-PNIC: provide information what physical NIC a VM actually using. | |
ESXTOP with Perfmon / esxplot / VisualESXTOP
https://communities.vmware.com/docs/DOC-9279
http://www.yellow-bricks.com/esxtop/
http://professionalvmware.com/2012/05/vbrownbag-follow-up-vstorage-troubleshooting-w-nathan-small/
http://labs.vmware.com/flings/esxplot
https://labs.vmware.com/flings/visualesxtop
vSCSIstats
http://communities.vmware.com/docs/DOC-10095
http://www.yellow-bricks.com/2009/12/17/vscsistats/
http://cormachogan.com/2013/07/10/getting-started-with-vscsistats/
vSAN analyzer
—
Troubleshooting & Performance best-practices:
