1.- La llamada.
Los problemas de performance son un tema recurrente en la vida de un administrador de sistemas, normalmente suelen llegar en forma de incidencia bajo el eufemismo "lentitud en el sistema" o parecido, que en realidad significa "No tenemos ni idea de que está pasando". Ante estas situaciones mis sentimientos son encontrados. Por un lado tienes la oportunidad de usar tus conocimientos e investigar el origen de una incidencia, lo cual no deja de ser atractivo. Los problemas empiezan cuando el diagnóstico no depende de ti solo, en realidad suele hacer falta la colaboración de la gente de comunicaciones, BB.DD., aplicaciones, etc. Invariablemente siempre te encuentras con algún personaje más interesado en pasar el marrón a otro que en colaborar para encontrar la solución.
Los jefes
Hay otro elemento que todavía no he mencionado, tu jefe, o aun peor, el
jefe de tu jefe. Normalmente las situaciones donde el
performance se ve
degradado suele venir acompañado de cierto nerviosismo por parte de las
grandes esferas, en lo que a ti respeta se traduce en presión para
resolver el problema lo antes posible.
Sin embargo un diagnóstico de este tipo suele llevar bastante tiempo,
muchas veces es complicado dar con la causa raíz del problema. No obstante, es
importante que sepas dar una primera valoración rápida de lo que
esta ocurriendo en el equipo. Un prolongado silencio puede dar pie a
teorías
de lo más disparatadas por parte de tus colegas, que en el peor de los casos
podrían ser creídas por tus responsables.
Los problemas tienen un origen
Si, es obvio verdad? Cuando se produce una degradación del
sistema siempre hay una causa. Algo que parece indiscutible es discutido
muchas veces en el mundillo de la informática, cuantas veces
habré escuchado frases del tipo, "Se habrá quedado algo
colgado", "Habrá bloqueos", "Está
pillado", etc. y después se suelen acompañarse de la sugerencia
"reiniciemos el equipo".
Reiniciar vs no reiniciar
Salvo que tu puesto de trabajo corra peligro nunca reinicies un equipo sin haber tratado de realizar un diagnóstico antes, por suerte dispones de un sistema sumamente observable, es decir, tienes a tu mano una serie de herramientas que, junto con el conocimiento necesario, te permitirán determinar la causa del problema. Aunque un reinicio a priori puede solucionar las cosas en un elevado porcentaje de ocasiones, solo conseguirás que la incidencia reaparezca en unas horas o días y tu nivel de conocimiento de la causa seguirá siendo el mismo que antes, es decir, 0. Créeme, aunque muchas veces tus responsables no sean conscientes, seguro que prefieren tener la producción degradada o incluso parada durante un rato a que la misma incidencia se reproduzca de forma cíclica. Si el problema es realmente crítico puedes obtar por generar un live core "#savecore -L" y realizar un análisis
posterior de la imagen del kernel. Ten en cuenta que en sistemas con mucha RAM
el volcado puede demorar un rato.
Primeras valoraciones
Lo que sigue no pretende ser una Biblia de los pasos a seguir, en ocasiones
puede ser necesario un mayor grado de profundización antes de valorar
la situación, otras veces el cuello de botella es tan evidente que
puedes obviar muchos de los pasos aquí descritos.
Tanteo:
Mi primer comando a ejecutar suele ser#w. Es un comando ligero
con el que obtienes información bastante útil, el uptime del
equipo, su load average y los usuarios conectados junto al comando que
están ejecutando.
root@box # w 9:28am up 135 day(s), 18:29, 3 users, load average: 3.96, 3.67, 3.91 User tty login@ idle JCPU PCPU what explot pts/1 8:15am 1 9:48 sqlplus /script oracle pts/2 8:39am 50 tail -25f /opt/oracle/app/oracle sistemas pts/3 9:05am -bash
El load average es un parámetro engañoso, su nombre puede llevar a confusión, parece ser un calculo de la carga del sistema. Sin embargo es la media del número de threads en las run queues, es decir, un elevado load average puede ser síntoma de saturación de cpu pero no tiene en cuenta otros aspectos como puede ser memoria, i/o, red, etc.Comprobar recursos:
Uno de mis comandos preferidos es el vmstat, proporciona muchísima información a simple vista. Lo normal sería lanzar un#vmstat 5 y dejarlo un buen rato ejecutándose. La primera linea
son estadísticas desde que se arrancó el sistema, por lo que en
nuestro caso debe ser ignorada.
root@box # vmstat 5 kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr 2m m0 m1 m2 in sy cs us sy id 1 0 0 42157120 7573496 585 2219 1920 7 9 0 6 44 2 1 1 19612 34991 12905 42 15 43 0 0 0 41882080 7348816 546 2233 2175 0 0 0 0 35 0 0 0 12435 29385 6561 32 9 59 0 0 0 41882512 7344728 584 2393 2162 0 0 0 0 36 20 19 19 10922 32580 7231 28 9 63 0 0 0 41884936 7342656 628 2809 2174 0 0 0 0 35 0 0 0 11673 43611 8204 31 9 60 [...]
Varios son los datos interesantes para nuestra primera aproximación: La columna r: Es el número de procesos esperando en las run queues, idealmente debería ser 0, lo que indicaría que cualquier thread en condiciones de ser ejecutado ha encontrado un procesador libre. Si el valor de r supera el número de procesadores de nuestro sistema estamos empezando a saturar, si lo duplica estamos ante una situación de saturación y la performance empieza a verse degradada. La columna sr: Es el número de veces que se ha ejecutado el