En esta tercera entrega vamos a intentar resolver las preguntas más difíciles de contestar...
¿Qué contadores utilizar? ¿Y que significan esos valores?
Estas son las preguntas que siempre acabamos por hacer. ¿Qué contadores utilizo para medir…? ¿Y que significa si el valor es…? Y realmente estas son las más difíciles de responder.
Como hemos visto el funcionamiento del monitor del sistema no es demasiado complicado, pero escoger los contadores a monitorizar e interpretar los resultados obtenidos es más difícil. Y lo peor es que no hay una respuesta para estas preguntas. Cada caso requiere escoger unos contadores adecuados, estudiarlos, compararlos con otros, averiguar cual se desvía del comportamiento normal, saber como corregirlo…
En fin, que mas que una ciencia el analizar el rendimiento de un sistema parece un arte donde la experiencia y la intuición distinguen a aquellos que encuentran el problema (y la solución) de aquellos que sólo ven gráficas sin sentido en pantalla.
Pero no todo está perdido. Siempre hay unas pautas y unas sencillas reglas con las que podemos empezar a obtener resultados cuando medimos los 4 elementos esenciales del sistema: memoria, procesador, disco y red.
Vamos a ver como encontrar cuellos de botella en estos elementos de nuestro sistema o como se comportan para averiguar si necesitamos una actualización de hardware o un cambio en el modo de trabajo de nuestro servidor.
Monitorizar el procesador
Vamos a empezar con el procesador porque es el componente más fácil de analizar.
Lo primero es saber que tipo de servidor estamos analizando. No es lo mismo un controlador de dominio de Windows 2003 que no tiene otra función que un servidor de ficheros o que un servidor Web que además aloja un SQL Server. Nunca hay que olvidar cual es el entorno de trabajo en el que nos encontramos.
En el caso del procesador es fácil entender que puede darnos problemas si tenemos un servidor de bases de datos o un servidor de aplicaciones, pero que difícilmente el procesador será un problema en un servidor de ficheros o en un servidor de impresión.
Procesador: %tiempo del procesador: Este valor es un claro indicador de si nuestro problema está en el procesador. Si durante el funcionamiento de nuestro sistema este valor está constantemente por encima del 80% con periodos en el 100% necesitamos un procesador más potente o más procesadores.
Este excesivo uso del procesador también puede estar causado por una aplicación defectuosa (en muy pocos casos). Si tenemos la sospecha de que esto puede estar ocurriendo añadiremos el contador Proceso: %tiempo de procesador para averiguar cual es el proceso que está causando problemas.
Tener picos del 100% durante breves espacios de tiempo donde se ejecuta un proceso especial es un comportamiento normal. Y por si alguien tiene la tentación de decir que necesita un procesador más potente porque cuando realiza una copia de seguridad con compresión el contador está continuamente al 100% que lo olvide, porque acciones como usar programas de compresión, de análisis de virus y similares usan el 100% del procesador sin importar lo bueno que sea nuestro procesador.
Procesador: interrupciones/segundo: Esta medida nos dirá cuantas peticiones de interrupción ha sufrido el procesador por parte de dispositivos. Un número normal está entre 1000 y 1500. Yo no empezaría a preocuparme hasta llegar a unos 2000 aunque si este contador aumenta sin que aumente la actividad del sistema es un síntoma de que hay un problema de hardware con alguna tarjeta o disco.
Sistema: longitud de la cola del procesador: Este contador por un lado es difícil de entender (ahora lo explicaremos) y por otro sencillo de manejar.
Es sencillo de manejar porque si nos encontramos con un periodo de tiempo más o menos largo donde el valor es superior a 2 significa que tenemos un problema de congestión y que necesitamos más procesadores.
El contador nos muestra el número de procesos que están esperando en la cola del procesador, es decir, los procesos que están esperando en un determinado instante para ser ejecutados. El valor umbral de 2 es para un procesador. Si tenemos varios hay que dividir es numero que obtenemos entre en número de procesadores puesto que sólo hay una cola de espera aún con varios procesadores.
Hay más contadores que podemos tener en cuenta para ver el rendimiento de nuestro procesador, pero con estos tenemos suficiente para empezar.
Monitorizar la memoria
Optimizar la memoria en un servidor es relativamente sencillo. Cuanta más memoria mejor. De todos modos como siempre hay que pensar en que tipo de servidor queremos analizar. Por ejemplo si tenemos un SQL Server no hay duda de que la memoria puede ser uno de nuestros problemas. Si tenemos un servidor de dominio que no realiza ninguna otra tarea la memoria no va a ser nuestro cuello de botella.
Vamos a ver que contadores tenemos que observar en este caso
Memoria: Mbytes disponibles: Quizás el contador más interesante para empezar puesto que nos dice cuanta memoria tenemos disponible en este momento para servir páginas a las aplicaciones que demanden más memoria. Si hay pocos bytes disponibles previamente a asignar memoria a una aplicación hay que desalojar páginas de memoria al archivo de paginación con el coste que eso supone.
Por ejemplo si tenemos un servidor de bases de datos la ejecución de una consulta necesitará memoria disponible. Si tenemos un servidor de aplicaciones y alguien quiere ejecutar una nueva aplicación hay que tener memoria disponible.
El valor de este contador nunca debería bajar de 4 Mbytes aunque por experiencia si está por debajo de 8 Mbytes de manera habitual ya podéis pensar en añadir más RAM.
Memoria: páginas/s: Este es otro contador básico para saber si andamos escasos de memoria. Nos dice cuantas páginas de memoria se han leído o escrito a disco cuando nuestro sistema operativo no es capaz de encontrarlas en memoria RAM.
Si estamos cortos de memoria se verá afectado todo el sistema. Por un lado el tener que asignar páginas de disco endentece el proceso. Pasar páginas de memoria a disco y viceversa obliga al Virtual Memory Manager a usar tiempo de procesador para realizar estas operaciones. Y por último no olvidemos que estamos hablando de leer y escribir en disco, por lo que también se enlentece el acceso a disco.
¿Y cual es el valor correcto para este contador? Pues depende. Y aquí es muy atrevido dar un número (aunque lo haremos). Lo mejor sería ver este contador durante un tiempo en el que la actividad del sistema sea normal y cuando no haya ningún tipo de problema y usar ese valor como referencia. Pero como somos atrevidos vamos a decir que más de 20-30 páginas/s es un problema del que debemos preocuparnos. (Aunque este número depende mucho del software y hardware instalado)
Visión general: Una vez vistos estos dos contadores hay que hacer una pausa. He visto equipos con más de 10 Mbytes de RAM libre y con contadores de paginas/s por encima de 40. ¿Es esto posible? Pues sí. Un punto importante a la hora de monitorizar un sistema es no dejar que los árboles nos tapen el bosque. Un programa realizando una gran cantidad operaciones de acceso a datos que no están actualmente en memoria (como por ejemplo una base de datos accediendo a datos) puede producir valores muy altos de páginas/s. Para averiguar si lo que tenemos es un problema de RAM hay que monitorizar los dos contadores. Si la cantidad de memoria libre no decrece según aumenta el contador de páginas/s quiere decir que esas páginas/s de más no son producidas por una escasez de RAM sino por accesos a disco de alguna aplicación.
Memoria: fallos de página/s: Indica el número de fallos de página que ocurren en el procesador. Los fallos de página ocurren cuando un proceso del sistema hace referencia a una página de memoria virtual que no está actualmente en el espacio de trabajo de la memoria principal. Es la suma de los fallos de página de dos fuentes. Por un lado las páginas que se encuentran en RAM (soft page faults) y por otro las que hay que ir a buscar al fichero de paginación en el disco (hard page faults).
Memoria: páginas de entrada/s: Es el número de páginas leídas de disco para resolver referencias a memoria de páginas que no se encontraban en la memoria en ese momento. Este contador hay que mirarlo en relación al anterior. El número de fallos de página/s debería ser más del doble de las páginas de entrada/s (como siempre depende de nuestro sistema). La idea es que cuando hay un fallo de página la mayoría de esos fallos de página deberían resolverse mediante soft page faults sin necesidad de acceder a disco y por eso cuantas menos páginas de entrada tengamos mejor.
Monitorizar el fichero de paginación
El fichero de paginación es algo que nunca debería causarnos problemas, y si alguna vez es el origen de un bajo rendimiento no hay disculpa para no solucionarlo inmediatamente.
Simplemente decir que el fichero de paginación debería estar en un disco adecuado (no el de sistema) y si es posible repartido por dos discos distintos. Otra buena costumbre es asegurarse que tiene un tamaño fijo y no dejar que esté en un disco fragmentado.
Memoria: %uso: Es el porcentaje de archivos de paginación que están siendo utilizados. Por supuesto no debería pasar de 75% para tener siempre un margen de seguridad.
Monitorizar el acceso a disco
Lo primero que debemos saber es que los problemas de acceso a disco pueden ser causados no sólo por el disco, si no por otros elementos como vimos al hablar de la memoria (paginación excesiva) así que al hablar de monitorización de disco hay que tener siempre presentes los contadores que nos hablarán de memoria, procesador y red. Y como siempre no todos los tipos de servidores tendrán las mismas necesidades en cuanto a discos. Un servidor de ficheros tendrá necesidad de acceder a disco más que un servidor DNS, y un servidor de bases de datos mostrará resultados preocupantes en el disco que contiene los ficheros de log si no sabemos que esos ficheros están ahí.
Disco físico: escrituras/s lecturas/s: Escrituras y lecturas de disco por segundo es la frecuencia de estos tipos de operaciones en disco. Dependiendo del disco que tengamos el límite de operaciones I/O por segundo estará entre las 20 de un disco IDE normal hasta las 80 de un Ultra Wide SCSI. Este valor dependerá mucho de si las lecturas son secuenciales o aleatorias.
Disco físico: %Tiempo de disco: Es el porcentaje de tiempo en el cual la unidad de disco ha estado ocupada atendiendo peticiones de lectura y escritura. No debería estar muy por encima del 60% de manera habitual, y si nos lo encontramos por encima del 90% tenemos un problema.
Disco físico: longitud actual de la cola del disco: Esta medida nos muestra la cantidad de peticiones pendientes en el disco en el instante en que se recopilan los datos. Este contador puede reflejar de temporalmente un valor alto o bajo (no olvidemos que es una medida instantánea). Las peticiones a disco experimentan retrasos proporcionales a la longitud de la cola menos el número de discos que compongan el cilindro. La media de esta diferencia debería ser inferior a 2 para conseguir un buen rendimiento.
Si vamos a medir este contador durante una cantidad de tiempo considerable podemos recurrir al Disco físico: longitud media de la cola del disco que nos dará la media de la medida anterior en el intervalo de muestra.
Disco físico: longitud promedio de la cola de lectura de disco
Disco físico: longitud promedio de la cola de escritura de disco
Estas dos medidas están también muy relacionadas con la anterior y ambas deberían estar por debajo de 2. Si superan este valor de manera habitual tenemos un problema con la capacidad de nuestro disco para responder a las peticiones del sistema.
Disco físico: media de bytes por transferencia: Este es otro contador interesante porque nos da una medida del rendimiento del disco y del bus (IDE o SCSI) que lo conecta al equipo. Esta media es el número de bytes que se transfieren al disco durante operaciones de lectura o escritura. Cuanto más alto sea este valor mejor.
Disco físico: media en segundos/transferencia: La Media en segundos por transferencia es la duración media de las transferencias de disco. Si este valor supera 0.3 podemos estar ante algún problema de hardware con nuestro disco, aunque este valor como siempre dependerá del fabricante y la configuración que tengamos.
Disco físico: media en bytes/transferencia: La Media de bytes por transferencia es el promedio de bytes transferidos desde o hacia el disco durante las operaciones de lectura o escritura. Este valor dependerá de si hacemos lecturas (o escrituras) secuenciales o aleatorias. Para empezar un buen valor sería tener unos 20Kb por transferencia.
Si tenemos problemas con nuestro disco y es el elemento que hace que nuestro sistema se ralentice hay una serie de medidas a tomar en consideración.
La primera y más obvia es comprar mejor hardware. Pero no es la única ni la mejor de las soluciones.
Desfragmentar el disco es una tarea a la que no se da mucha importancia (no os creáis que con 2000 o 2003 no hace falta desfragmentar el disco) y creedme si os digo que después de desfragmentar se pueden ver resultados sorprendentes en el rendimiento de los discos.
Otro parámetro interesante es la cantidad de disco ocupado. Si tenemos más del 70% del espacio de disco ocupado empezaremos a ver como se degradan los parámetros de acceso al mismo.
Para agilizar el número de operaciones de Entrada/Salida de nuestro sistema de discos también podemos recurrir a los sistemas RAID.
Y por último conocer el entorno en el que nos movemos. Si tenemos un servidor de bases de datos debemos utilizar un disco exclusivamente para los ficheros de transacciones. Si tenemos un servidor de páginas Web tendremos un montón de lecturas aleatorias en nuestro disco y no es conveniente que eso ocurra en el disco del sistema. Si trabajamos con servidores de ficheros no estaría mal pensar en usar DFS.
En resumen, un poco de sentido común hace maravillas con los discos.