Introducción.
Habitualmente, las monitorizaciones realizadas durante las pruebas de carga, deben de incluir monitorizaciones sobre
- El estado global de la máquina
- Estado específico de los procesos que dan servicio a la aplicación
- Estado de las comunicaciones
Las monitorizaciones se pueden realizar
- bien mediante una herramienta específica de terceros (léase Introscope, HP Diagnostics) las cuales permiten monitorizar tanto global, como especializadamente la máquina y procesos asociados. Tienen el problema de ser herramientas de pago y que precisan de la instalación de “sondas” ,agentes e incluso una infraestructura específica.
- Mediante comandos del sistema operativo. Esto permite realizar monitorizaciones sin gasto adicional , ni infraestructuras específicas, aunque tiene limitaciones y precisan en ocasiones de permisos mediante sudo
Tanto las herramientas externas, como los comandos generan un consumo adicional en las máquinas a monitorizar. Es conveniente por lo tanto, ejecutar estos comandos en intervalos adecuados a la duración de la prueba para tomar medidas sin que afecten en demasía al comportamiento del sistema durante la ejecución.
Memoria compartida.
Habitualmente dentro de la categoría de monitorización mediante comandos usamos clásicos como vmstat o ps ,bien formateado para generar valores específicos (ps –eo PID,PPID,pcpu,rss,args ) o mediante parámetros de ejecución específicos de una versión de ps (ps –aux).
Sin embargo, tenemos algunas limitaciones con métricas recogidas por este comando, como por ejemplo, el comportamiento de la memoria asociada a un proceso, cuando se comparte memoria entre distintos procesos de una instancia de Oracle.
En estos casos, vemos que la memoria que refleja un ps sobre uno de dichos los procesos, muestra la suma total de la memoria compartida (RSS).
Ilustración 1. Salida del comando ps con cadena de formato
En este caso, monitorizado sobre un proceso con PID específico (7076), nos indica que, el campo RSS ocupa 597880 KBytes. Esta memoria es la compartida por todos los procesos de la instancia de Oracle.
Sin embargo, podemos usar el comando pmap, el cual nos indica de manera desglosada el consumo de memoria compartida, y los permisos que se tiene sobre cada página de la memoria asociada el proceso. Sin embargo, este es un comando privilegiado, que sólo puede ejecutar el usuario que está lanzando el proceso que se quiere monitorizar
$ sudo -u
7076: oracleIESECFI0 (LOCAL=NO)
Address Kbytes RSS Anon Locked Mode Mapped File
0000000100000000 51992 50312 - - r-x-- oracle
00000001033C4000 720 680 64 - rwx-- oracle
0000000103478000 504 392 160 - rwx-- [ heap ]
0000000380000000 544768 544768 - 544768 rwxsR [ ismhmid=0x1000032 ]
FFFFFFFF7D100000 64 64 32 - rwx-- [ anon ]
FFFFFFFF7D200000 640 192 - - r-x-- libm.so.2
FFFFFFFF7D300000 16 16 16 - rw--R [ anon ]
FFFFFFFF7D350000 80 80 40 - rw--R [ anon ]
FFFFFFFF7D366000 40 40 32 - rw--R [ anon ]
FFFFFFFF7D39E000 40 24 8 - rwx-- libm.so.2
FFFFFFFF7D400000 56 16 - - r-x-- libmd.so.1
FFFFFFFF7D50E000 8 8 - - rwx-- libmd.so.1
FFFFFFFF7D600000 24 24 - - r-x-- libm.so.1
FFFFFFFF7D704000 8 8 8 - rwx-- libm.so.1
FFFFFFFF7D800000 8 8 - - r-x-- libkstat.so.1
FFFFFFFF7D902000 8 8 - - rwx-- libkstat.so.1
FFFFFFFF7DA00000 32 24 - - r-x-- librt.so.1
FFFFFFFF7DB08000 8 8 8 - rwx-- librt.so.1
FFFFFFFF7DC00000 32 32 - - r-x-- libaio.so.1
FFFFFFFF7DD08000 8 8 8 - rwx-- libaio.so.1
FFFFFFFF7DE00000 944 760 - - r-x-- libc.so.1
FFFFFFFF7DF00000 64 32 24 - rwx-- [ anon ]
FFFFFFFF7DFEC000 64 64 48 - rwx-- libc.so.1
FFFFFFFF7DFFC000 8 8 8 - rwx-- libc.so.1
FFFFFFFF7E000000 8 8 - - r-x-- libdl.so.1
FFFFFFFF7E102000 8 8 8 - rwx-- libdl.so.1
FFFFFFFF7E200000 32 16 - - r-x-- libgen.so.1
FFFFFFFF7E308000 8 8 - - rwx-- libgen.so.1
FFFFFFFF7E400000 56 40 - - r-x-- libsocket.so.1
FFFFFFFF7E500000 8 8 8 - rwx-- [ anon ]
FFFFFFFF7E50E000 16 16 16 - rwx-- libsocket.so.1
FFFFFFFF7E600000 688 272 - - r-x-- libnsl.so.1
FFFFFFFF7E700000 8 8 8 - rwx-- [ anon ]
FFFFFFFF7E7AC000 64 64 48 - rwx-- libnsl.so.1
FFFFFFFF7E7BC000 32 32 8 - rwx-- libnsl.so.1
FFFFFFFF7E800000 5384 1704 - - r-x-- libjox9.so
FFFFFFFF7EE00000 8 8 8 - rwx-- [ anon ]
FFFFFFFF7EE40000 376 280 112 - rwx-- libjox9.so
FFFFFFFF7EE9E000 16 - - - rwx-- libjox9.so
FFFFFFFF7EF00000 32 24 - - r-x-- libskgxn9.so
FFFFFFFF7F000000 8 8 8 - rwx-- [ anon ]
FFFFFFFF7F006000 8 8 - - rwx-- libskgxn9.so
FFFFFFFF7F100000 8 8 - - r-x-- libskgxp9.so
FFFFFFFF7F200000 8 8 - - rwx-- libskgxp9.so
FFFFFFFF7F300000 8 8 - - r-x-- libodmd9.so
FFFFFFFF7F400000 8 8 8 - rwx-- libodmd9.so
FFFFFFFF7F500000 24 16 8 - rwx-- [ anon ]
FFFFFFFF7F600000 176 176 - - r-x-- ld.so.1
FFFFFFFF7F700000 8 8 8 - rwx-- [ anon ]
FFFFFFFF7F72C000 16 16 16 - rwx-- ld.so.1
FFFFFFFF7F78C000 8 8 - - rwxs- [ anon ]
FFFFFFFF7FFF0000 64 64 40 - rw--- [ stack ]
---------------- ---------- ---------- ---------- ----------
total Kb 607224 600408 760 544768
|
Tabla 1. Salida del comando pmap sobre un proceso de Oracle
Podemos ver que la columna “Locked mode” indica el modo de acceso al segmento de memoria indicado. En este caso, debemos fijarnos sólo en aquellos valores de la columna que sean
- rwx-
- rw---
El valor de la columna que incluya el campo “s”, indica memoria “shared” ,es decir, compartida.
El resto de columnas de la muestra, reflejan memorias de uso compartido con el resto de procesos lanzados de la instancia de Oracle a la que pertenece.
Como idea, un posible script para sacar la monitorización de memoria usada en exclusiva por un proceso sería
sudo -u USUARIO /bin/pmap -x $1 | grep -v Address | awk ' BEGIN {
primero=1
}
/:/ {
if(primero==1) {
primero=0;
} else {
print “tiempo,"$1, proc, ",", suma;
}
suma=0;
proc=$0;
}
$6 !~ /s/ {
if (($6 =="rw---") || ($6 =="rwx--"))
suma=suma+$3;
}
END {
print “tiempo,”,$1,proc,",",suma;
}'
Donde USUARIO sería el usuario que ejecuta el proceso a monitorizar y $1 el pid del proceso.
|
Threads en Solaris.Siguiendo el hilo
La monitorización específica de procesos también puede extenderse al uso de los threads activos . Para ello un comando útil bajo Unix (versión Solaris) es prstat
Ilustración 2. Salida del comando prstat sobre un usuario ($prstat -u hzweb)
El comando admite varias opciones de ejecución , dependiendo de si se quiere
- monitorizar un proceso/s específico/s $ prstat –p PIDLIST
- monitorizar los procesos lanzados por un/os usuario/s $ prstat –U UIDLIST
- monitorizar los threads (en Solaris “Light weight processes”) en ejecución ($ prstat –L –U UIDLIST –p PIDLIST
Este último caso es quizás el más interesante para observar el comportamiento de todos los threads asociados al proceso. Ya que el número de threads asociados puede superar el tamaño de líneas del terminal , lo ideal es lanzar el comando con alguna de las opciones de ordenación que permiten establecer
También podemos conocer el número total de threads asociados, usando la opción “-t” con el comando
$ prstat -t -L -U UIDLIST
Ilustración 3.Salida del comando prstat sobre procesos de dos usuarios
El comando que se puede usar para conocer cuáles son los hilos que están consumiendo más recurso de procesador (opción “-s cpu)” y en qué CPUs físicas
$ prstat –L –p PID –s cpu
Ilustración 4.Salida del comando prstat sobre los threads de un proceso de usuario
La columna STATE permite distinguir los procesos en ejecución en un procesador determinado (cpuN), en cola de ejecución (run) en espera (sleep) o, llegado el caso desechados (zombi) o parados (stop).
En resumen ,este comando, nos permite observar
- Número de threads asociados a un proceso
- Consumo desglosado por thread
- Balanceo y distribución de los threads en un sistema multiprocesador
- Bloqueos presentes en los threads
Con estos valores, podemos por lo tanto detectar si un sistema gestionan adecuadamente los hilos de ejecución de una JVM y sus consumos asociados (por ejemplo ,en un servidor weblogic o SunOne )
En la próxima entrega tratermos sobre la localización de los procesos que generan elevado consumo de espacio en disco (lo cual afecta decisivamente al rendimiento) ,así como el agotamiento de descriptores de fichero: lsof. ¡El comando con el manual incomprensible!
