7.- Las estadísticas.
Introducción
Todos los sistemas suelen tener un patrón de carga habitual, es
frecuente que un administrador se lo conozca de memoria, especialmente si tiene
pocos servidores a su cargo. Sin embargo, es importante guardar un registro.
Algunos motivos pueden ser:
- Si administras muchos equipos es imposible conocer el patrón de
carga de cada uno de ellos.
- Aunque lo conozcas siempre habrá alguien dispuesto a discutirlo,
especialmente compañeros de otras áreas más interesados en
escurrir el bulto que en solucionar el problema. En estas situaciones tener un
histórico almacenado te evitará enzarzarte en discusiones
inútiles.
- Si tu herramienta es buena puedes acceder a datos que habitualmente no
compruebas.
- Muchas más que seguro que se os ocurren a vosotros mismos. :)
Es sumamente importante conocer (o poder consultar) el
patrón
de carga habitual en el equipo donde tenemos la perdida de
rendimiento, si esa información no está disponible nos
dificultará detectar el origen de esta.
Las herramientas de monitorización
Hay herramientas de monitorización realmente estupendas, algunas
mediocres y muchas pésimas. El problema siempre suele ser el mismo, tu
no la vas a poder escoger, ese tipo de decisiones las suelen tomar unas
personas que van con corbata y se sientan hablar con comerciales (que
también llevan corbata) y que, desde luego, su principal
preocupación es que el producto escogido sea la mejor solución
técnica posible para vuestras necesidades... o no.
Si eres afortunado y cuentas con una herramienta que almacena datos de todos
los parámetros que necesitas, los presenta de forma que es fácil
interpretarlos y además funciona relativamente ágil, enciende
un cirio a los dioses del binario pues te han bendecido. Lo normal es que la herramienta
con la que vayas a lidiar tenga alguna (o muchas) carencias importantes.
Los scripts
Una buena forma de paliar las deficiencias que pueda haber en tu sistema de
monitorización es programar una tarea en el crontab que ejecute un
script, y almacenar su salida en un fichero/s para posteriormente ser
consultada.
Puedes optar por desarrollarlo tu mismo, sin embargo es fácil encontrar
scripts muy completos ya hechos y que puedes adaptar rápidamente a tus
necesidades.
Personalmente habitualmente suelo usar
sys_diag de
Todd A.
Jobson, muy completo y personalizable.
Que datos debo almacenar?
Normalmente no podremos almacenar todos los datos que queremos, así que
es importante seleccionar aquellos que nos definan de forma más fiable
los patrones de carga de nuestros equipos. La siguiente lista es de
mínimos y orientativa, dependiendo del tipo de servicio que ofrezca
nuestro sistema puede ser interesante algún dato adicional.
- Procesos, threads y sus microstados (prstat -m).
- Cantidad de procesos en las run queues.
- % de tiempo de sistema, usuario e idle.
- Llamadas al sistema por proceso.
- Llamadas al sistema totales.
- Número de cambios de contexto (voluntarios e
involuntarios).
- Cantidad de memoria usada.
- Throughput en los distintos dispositivos.
- Listado de sockets y su estado.
- Salida de un lockstat.
- etc
A efectos prácticos disponer de la salida de un prstat, prstat -m,
vmstat, iostat, netstat y lockstat nos proporcionará datos suficientes para
constatar las desviaciones que se han producido.
El patrón de carga es distinto según la hora del día
dependiendo de la actividad que se está realizando, así que
asegúrate que tienes muestras de las distintas franjas.
Conclusión
En muchos casos careceremos de capacidad de análisis si carecemos de un
histórico de la carga del sistema, en general usaremos una herramienta
de monitorización a la que probablemente necesitaremos complementar con
algún script local.
