Buscar en este blog

18.10.12

Búsqueda de 'bottlenecks' en VMWare ESX/ESXi con ESXTOP

Elementos de visualización:

c - CPU
m - Memoria
n - Network
d - Interfaces de disco (HBA)
u - Discos físicos conectados a HBAs (LUN)
v - Discos virtuales de las VMs (vmdk)

Opciones genéricas de visualización:

s - Segundos de refresco
v - Mostrar solo VMs
f - Añadir/Eliminar campos a mostrar
o - Ordenación de campos
L - Número de caracteres a mostrar por campo (util si los nombres de las VMs son muy largos)
2 - Resaltar fila hacia abajo
8 - Resaltar fila hacia arriba
4 - Eliminar fila de la visualización

Búsqueda de cuellos de botella relativos a recursos de CPU física


    #esxtop
    c
    s 2
    L 45

Campos significativos:

CPU load average. Estos valores son los clásicos de carga media a 1, 5 y 15 minutos sobre los procesadores. Cuanto más se aproximen a 0, mejor.
 Los valores "PCPU USED (%)" y "PCPU UTIL(%)" indican la carga de las CPUs físicas (por core). Cuanto más se acerquen al 100% significará que menos ciclos de cpu libres quedan para picos de carga de las VMs o nuevas VMs. Es decir, sobresuscripción; se ha alcanzado el límite de los recursos de cpu. Por encima del 90% de uso sostenido comienza a se problemático teniendo que cuenta que la carga física es variable en función de la carga de las cpu virtuales.
Los valores por core de estas medidas pueden estar equilibrados o descompensados. Si la descompensación de carga entre unos cores y otros es muy grande, indica problemas de afinidad. Para mantener un grado aceptable de afinidad y no perjudicar el rendimiento, no se recomienda crear máquinas virtuales con mayor número de vCPUs que el número de cores de cada procesador físico (4 en caso de quad-core).

CPU de máquinas virtuales


    #esxtop
    c
    s 2
    L 45
Para un determinado World (VM):
  • %RUN: Ciclos de cpu que la máquina consume respecto a los procesadores virtuales que se le han asignado. Es el valor de carga de cpu que encontraríamos en las estadísticas del OS de la propia máquina.
  • %SYS: Ciclos de cpu de sobrecarga por I/O que el hypervisor debe usar para las operaciones de IO de la máquina virtual.
  • %USED: ~(%RUN + $SYS). Valor real de cpu que la VM está consumiendo.
  • %MLMTD: Ciclos de cpu que no se han podido ejecutar porque se viola un límite de cpu establecido para esa máquina. Es util para saber si una máquina que tiene un límite lo supera. Si este valor permanece en 0.00, el límite podría ampliarse aun más.
  • %RDY: Quizá el valor más representativo. Este valor indica la cantidad de tiempo que las vCPU de la VM ha solicitado ejecución de instrucciones en el procesador físico, pero ha tenido que esperar porque no había recursos para darle. Este valor debe estar lo más próximo a 0. Pro encima de 0 significa que la VM encola ciclos de cpu sobre el procesador físico. Hasta 5% puede ser aceptable. Por encima del 10% los problemas de rendimiento son bastante graves e indican una sobrecarga de los recusos de cpu físicos. Es el valor más representativo de que se han agotado los recursos.
  • Tiempos de espera por IO: ~(%WAIT - %IDLE)
  • %SWPWT: Tiempo de espera por información que está en swap. Este valor distinto de 0.00 es desastroso. Indica que el ESX está swapeando la máquina sin conocimiento de la misma. Los accesos a memoria se ralentizarán en al menos un orden de magnitud. Indica alta sobresuscripción.

Memoria física (pRAM)

    #esxtop
    m
    s 2
    L 45

De entre los valores globales:
  • MEM overcommit avg: De forma genérica, cantidad de memoria que ha tenido que ser swapeada por sobresuscripción. Idealmente estos valores deberían ser 0.00. El valor viene dado en 'tantos por uno', de forma que 0.20 indica un 20%. Es una forma de saber no solo la existencia de sobresuscripción, sino de cuanto representa.
  • PMEM  /MB: Uso de la memoria física. Cantidad total, usada y libre.
  • VMKMEM, COSMEM: Uso de memoria de la "Console Of Service"
  • SWAP  /MB: Ritmo al que swapea el ESX. El valor ideal es 0.
  • MEMCTL/MB: Cantidad de memoria que el ESX ha recuperado de las VMs haciendo Ballooning. El valor ideal es '0 curr'.

Memoria de las máquinas virtuales (vRAM)

    #esxtop
    m
    s 2
    L 45
   
Para un determinado World (VM):
  • MEMSZ: Memoria (MBs) asignadas a la configuración de la VM
  • GRANT: Memoria (MBs) que ya ha sido otorgada a la VM   
  • SZTGT: Memoria (MBs) GRANT + overhead. Si el overhead es grande, este valor puede superar el MEMSZ.
  • Overhead (OVHD, OVHDMAX, OVHDUW): El overhead es la cantidad de memoria que el ESX necesita para mantener una determinada máquina en funcionamiento. Almacena metadatos y depende del número de procesadores virtuales y memoria virtual de una máquina. Toda VM precisa una cantidad de memoria overhead. al menos habrá una cantidad fija de overhead (OVHDUW) dependiente casi únicamente de la cantidad de recursos, otra (OVHD) para el resource pool (frame-buffers, etc) y una cantidad máxima (OVHDMAX) que el ESX podría llegar a reclamar para el correcto funcionamiento de la máquina. Como al menos una cantidad de overhead es fija y depende de los recursos asignados a la máquina (número de cpus, RAM...), conviene saber que toda máquina sobredimensionada no solo compromete los recusos propios de su definición, sino también los recursos de overhead, que crecen a medida que la máquina tiene más recursos asignadso.
  •         SW*: Ritmo al que la máquina está haciendo swapping. Cuando una VM swapea su rendimiento se ve afectado.

Disco

    Los cuellos de botella en el almacenamiento suelen estar en tres posibles sitios: La interfaces de almacenameinto (HBAs, etc), los sistemas de almacenamiento externos o discos físicos o en último lugar en el acceso a discos virtuales de las propias máquinas, aunque estos últimos suelen derivar de alguno de los anteriores.

    Monitorización de las HBA

        #esxtop
        d
        s 2
        f

    Monitorización del acceso a disco físico (LUNs)

        #esxtop
        u
        s 2
        f

    Monitorización del acceso a discos virtuales por parte de las VMs (vmdks)

        #esxtop
        v
        s 2
        L 45
        f

Interpretación de valores.

        Latencias:
  • KAVG: Latencia de los comandos de acceso a disco del VMKernel. Es la latencia que se produce desde que un dato debe ser pedido a disco hasta que el VMKernel del ESX procesa la petición. No incluye el acceso real al dato, sino solo lo que le lleva al ESX ejecutar los comandos de petición. Debe estar muy próximo a cero salvo que el ESX esté sobrecargado y tenga que encolar comandos de IO a disco. Hasta 0.05 son valores aceptables.
  • DAVG: Latencia de entrada salida del almacenamiento. Es la latencia desde que el ESX ha realizado los comandos de petición (KAVG) hasta que el sistema de almacenamiento le ha devuelto el dato. Implica el tiempo que el almacenamiento tarda en posicionar las cabezas en los disco, leer y devolver la información. Como este valor no depende del ESX, debe compararse con los valores que son óptimos para el sistema de almacenamiento. De forma estandar, valores por encima de 20 se consideran latencias altas.
  • GAVG: (KAVG + DAVG). Es la latencia completa de una petición de acceso a disco. Si este valor no es óptimo se debe comprobar si es devido a KAVG o a DAVG. Este es el valor de latencia que percive la VM.
        IOPS:
  • CMDS/s, READS/s, WRITES/s: IOPS totales, de lectura y de escritura. Conviene comparar estos valores con los rangos que acepta el almacenamiento para ver si se está superando el límite.
MBREAD/s, MBWRTN/s: Ritmo al que se lee/escribe.
Problemas/Errores:
  • ABRTS/s: Comandos "Abort" por segundo. Se producen cuando el VMKernel solicita un acceso a disco pero el almacenamiento no es capaz de propocionarselo a tiempo. En ese momento se produce un comando Abort. El valor óptimo es 0.00, que indica que todas las peticiones son atendidas (aunque sus latencias pueden ser altas). 
  • RESETS/s: Similar al anterior pero con comandos 'Reset'. Indica el número de reseteos del bus SCSI. El valor óptimo es 0.00. Si crece podría deberse a desconexiones intermitentes del almacenamiento y supone un serio problema.
  • RESV/s: Número de reservas SCSI por segundo. Un número alto (>20) indica demasiadas VMs por LUN. Este valor toma sentido al cruzarlo con el siguiente.
  • CONS/s: Número de conflictos SCSI por segundo. El valor ideal es 0.00

Networking   

    #esxtop
    n
    s 2
    L 45
    f

  1.     Relativo a las interfaces físicas del ESX: Filas "vmnic*"
  2.     Relativo a las interfaces virtuales de las VMs: Filas con nombre de cada VM
Interpretación de valores:
  • PKTTX/s: Paquetes transmitidos por segundo (Diferenciar lo que sale por cada vmnic de lo de las VMs).
  •  MbTX/s:  Mb's transmitidos por segundo (IDEM)
  • PTTRX/s: Paquetes recibidos por segundo (IDEM)
  • MbRX/s:  Mb's recibidos por segundo (IDEM)
  • %DRPTX / %DRPRX: Los valores más representativos. Indican la cantidad de paquetes que no pueden ser encolados ni atendidos para envío o recepción y se han perdido. El valor ideal para ambos es 0.00. Valores superiores indican un cuello de botella la red. Si se 'dropean' paquetes en las interfaces físicas (vmnic*), indica que las VMs piden acceso a la red a un ritmo mayor de lo que el ESX puede atender (superior al ancho de banda de la interfaz). Si se dropean en las VMs, indica que la VM intenta sacar paquetes de su interfaz virtual a mayor ritmo que el ancho de banda de lo que es posible. Normalmente no se verá una VM dropeando paquetes sin que además exista un dropeo en las interfaces físicas salvo que el ancho de banda de las vmnic* sea mucho mayor que el de las interfaces virtuales.    

Referencias:

http://communities.vmware.com/docs/DOC-9279
http://communities.vmware.com/docs/DOC-11812
http://hispavirt.com/tag/esxtop/
http://www.windowsitpro.com/article/virtualization2/q-how-can-i-use-esxtop-to-identify-storage-performance-problems-