Uso de memoria RAM por proceso en Linux

La salida del clásico comando:
ps aux
...suele ser suficiente para ver el consumo de memoria de cada proceso.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  10644   708 ?        Ss   jun30   0:05 init [2] 
root         2  0.0  0.0      0     0 ?        S    jun30   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    jun30   0:14 [ksoftirqd/0]
root         6  0.0  0.0      0     0 ?        S    jun30   0:07 [migration/0]
[...]

USER: Propietario del proceso
PID: Identificador del proceso
%CPU: Relación de tiempo que el proceso usa CPU respecto al que está corriendo. Ojo, no es sobre el total del sistema.
%MEM: Relación de memoria (no swapeada) que el proceso usa respecto al total del sistema.
VSZ: Memoria virtual usada por el proceso completo.
RSS: Resident Set Size. Memoria no swapeada usada por el proceso.
TTY: Terminal asociado.
STAT: Estado del proceso.
START: Fecha de inicio del proceso.
TIME: Total de CPU usado desde que se inició.
COMMAND: Comando que lanzó el proceso.

Buceando por Internet he encontrado algunas filigranas dignas de mención y enormemente útiles para obtener la misma información:

  • Ordenado por orden de consumo:
ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS

  • Human readable:
 ps -eo size,pid,user,command | sort -rn | awk '{ hr[1024^2]="GB"; hr[1024]="MB"; for (x=1024^3; x>=1024; x/=1024) { if ($1>=x) { printf ("%-6.2f %s ", $1/x, hr[x]); break } } } { printf ("%-6s %-10s ", $2, $3) } { for ( x=4 ; x<=NF ; x++ ) { printf ("%s ",$x) } print ("\n") }'
  • Un script python fantástico
 Private  +   Shared  =  RAM used    Program

 80.0 KiB +  22.5 KiB = 102.5 KiB    init
116.0 KiB +  12.5 KiB = 128.5 KiB    minissdpd
116.0 KiB +  14.5 KiB = 130.5 KiB    chrome-sandbox
148.0 KiB +  20.5 KiB = 168.5 KiB    in.tftpd
[...]
101.6 MiB + 734.5 KiB = 102.3 MiB    nxserver.bin (2)
111.0 MiB +   1.4 MiB = 112.5 MiB    remmina
118.9 MiB +   6.1 MiB = 125.0 MiB    Xorg
134.9 MiB +  21.0 MiB = 155.9 MiB    chrome (5)
199.1 MiB +   3.7 MiB = 202.9 MiB    thunderbird
468.7 MiB +   5.5 MiB = 474.3 MiB    firefox
---------------------------------
                          1.7 GiB
=================================

¿Quien está consumiendo SWAP?

Excelente linea de comando para saber que procesos están ocupando SWAP y cuanto:


 for i in $( ls -d /proc/[0-9]* ) ; do SWAP=$(egrep --color '^VmSwap:[[:space:]]*[^0 ][0-9]* kB' "$i/status" 2>/dev/null ) && { cat "$i/cmdline" ; echo -n " (" $( basename $i ) ; echo -n "): " ; echo $( echo $SWAP | tr -s ' ' | cut -d' ' -f2- ) ; } ; done | sort -t':' -k2 -n

Nota: Este código no es mio. Lo encontré en Internet hace tiempo y tomé nota. Si eres la fuente original, por favor pásame el enlace para referenciarlo. Gracias.

Comandos útiles para "Space Reclaim"

Especialmente si se utilizan volúmenes de almacenamiento en SAN que están siendo ofrecidos en formato thin, es muy habitual que las salidas de comandos df no coincidan con los espacios en uso reportados por los propios sistemas SAN.
Esto se debe a que la mayoría de sistemas operativos no ejecutan la función unmap o trim cuando eliminan un archivo (conjunto de bloques en general), por lo que la SAN no es consciente de que ese espacio vuelve a estar libre.

Algunos sistemas de ficheros como Ext4 lo hacen automáticamente si se montan con la opción discard, pero no es lo habitual.

En casi todos los sistemas lo que sí existe es alguna forma de hacer un barrido al sistema de archivos para que ejecute las llamadas unmap sobre todos los bloques liberados para que la SAN se de por enterada. Son los siguientes:

Linux
#> fstrim /mountpoint

Vmware ESXi (>5)
#> cd /vmfs/volumes/DATASTORENAME
#> vmkfstool -y 60

El parámetro 60 hace referencia al porcentaje de espacio libre que se va a intentar reclamar. Este puede/debe ser ajustado de forma manual, pero 60 es un buen valor para comenzar y así lo recomienda VMWare.

Referencias:

http://linoxide.com/file-system/linux-reclaim-storage-space-ext4-unmap-feature/

Gestión de hora en dominio windows


Escenario

Un servidor de hora fiable dentro de una organización o acceso a uno (vg.- hora.roa.es).
Controladores de dominio de windows deben tomar la hora de este servidor de hora para servidrla a través del PDC al resto de servidores y PCs Windows (esto es automático).

Comandos


Comprobar de donde toma la hora un "Domain Controller":
w32tm /query /configuration

Forzar una resincronización
w32tm /resync

Añadir el servidor externo como proveedor de hora:
w32tm /config /syncfromflags:manual /manualpeerlist: hora.roa.es
w32tm /config /update

Recomendación

Hacer que todos los controladores de dominio de la organización tengan las mismas fuentes de hora.

Delegar control total de una OU en OpenLDAP a un usuario

"OU" a delegar:

 ou=clientes,ou=People,dc=test,dc=com

Creación del usuario:

 Este es el ldif del nuevo usuario creado en la raíz del árbol:

cn=subadmin,dc=test,dc=com
dn: cn=subadmin,dc=test,dc=com
cn: subadmin
objectclass: simpleSecurityObject
objectclass: organizationalRole
objectclass: top
userpassword: {SSHA}k2eAXwOOKhrYR4aUadKCU6syRS3e6CqQ

ACL de escritura:

Aquí es donde se produce la magia. Editando el archivo "sldapd.conf" se introduce la ACL que otorga los permisos:

[...]
access to dn.children="ou=clientes,ou=People,dc=test,dc=com"
         by dn.base="cn=subadmin,dc=test,dc=com" write
[...]

 Reinicar el servicio slapd. 

#> /etc/init.d/slapd restart

Prueba

El usuario nuevo debería ser capaz de conectarse y crear/borrar/modificar objetos por debajo de la "OU" delegada.


Dos comandos útiles en ESXi 5.1 para iSCSI

 Eliminar el adaptador iSCSI software
 #esxcli iscsi software set -e false

Cambiar el IQN del adaptador iSCSI
 # esxcli iscsi adapter set -A vmhba33 -n iqn.1998-01.com.vmware:xxxxxxxxx
 # esxcli iscsi adapget get -A vmhba33

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-