Publiée le 10/05/2010 | Modifiée le 27/01/2014

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

esxtop-c-df

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

esxtop-m-bdjkq

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

esxtop-m-dg

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

esxtop-d-agj

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

esxtop-n-abcdefkl

%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:

https://communities.vmware.com/docs/DOC-24046

Les commentaires sont fermés.