Preparación para el examen 301 del LPI, Tema 306: Planificación de capacidad

Guía de estudio para el examen Linux Professional de Nivel Senior (LPIC-3)

En este instructivo, Sean Walberg lo ayuda a prepararse para rendir el examen Senior Level Linux® Professional (LPIC-3) del Linux Professional Institute. En una serie de seis instructivos, Sean le enseña a monitorear los recursos de su sistema, a solucionar problemas de recursos y a analizar la capacidad de los sistemas.

Sean Walberg, Senior Network Engineer, P.Eng

Photo of Sean WalbergSean Walberg ha estado trabajando con Linux y UNIX desde 1994 en entornos de proveedores de servicios académicos, corporativos y de Internet. Ha escrito extensamente sobre la administración de los sistemas en los últimos años.



15-07-2011

Antes de comenzar

Conozca qué es lo que pueden enseñarle estos instructivos y cómo sacarles máximo provecho.

Acerca de esta serie

El Linux Professional Institute (LPI) certifica administradores de sistemas Linux a tres niveles: nivel junior (también llamado "nivel 1 de certificación"), nivel avanzado (también llamado "nivel 2 de certificación"), y nivel senior (también llamado "nivel 3 de certificación"). Para obtener el nivel 1 de certificación, se deben aprobar los exámenes 101 y 102. Para obtener el nivel 2 de certificación, se deben aprobar los exámenes 201 y 202. Para obtener el nivel 3 de certificación, se debe contar con una certificación activa de nivel avanzado y aprobar el examen 301 ("principal"). En este nivel, también puede requerirse aprobar exámenes adicionales sobre especialidades.

developerWorks ofrece instructivos para ayudarlo a prepararse para los cinco exámenes de certificación junior, avanzado y senior. Cada examen abarca varios temas, y cada tema tiene su correspondiente instructivo de autoaprendizaje en developerWorks. La Tabla 1 detalla los seis temas del examen 301 del LPI y su correspondiente instructivo en developerWorks.

Tabla 1. Examen 301 del LPI: Instructivos y temas
Tema del examen 301 del LPIInstructivo en developerWorksResumen del instructivo
Tema 301Preparación para el examen 301 del LPI:
Conceptos, arquitectura y diseño
Conozca acerca de los conceptos y la arquitectura de LDAP, cómo diseñar e implementar un directorio LDAP, y acerca de los esquemas.
Tema 302Preparación para el examen 301 del LPI:
Instalación y desarrollo
Aprenda cómo instalar, configurar y usar el software OpenLDAP.
Tema 303Preparación para el examen 301 del LPI:
Configuración
Aprenda cómo configurar el software OpenLDAP en detalle.
Tema 304Preparación para el examen 301 del LPI:
Uso
Aprenda cómo explorar el directorio y usar las herramientas de OpenLDAP.
Tema 305Preparación para el examen 301 del LPI:
Integración y migración
Aprenda cómo usar LDAP como fuente de datos para sus sistemas y aplicaciones.
Tema 306 Preparación para el examen 301 del LPI:
Planificación de capacidad
(Este instructivo.) Mida recursos, resuelva problemas de recursos y planifique para un futuro crecimiento. Vea en detalle los objetivos.

Para aprobar el examen 301 (y obtener la certificación del nivel 3), deben cumplirse las siguientes condiciones:

  • Usted debe tener varios años de experiencia en la instalación y el mantenimiento de Linux en un buen número de computadoras para diferentes finalidades.
  • Usted debe contar con experiencia en integración con diferentes tecnologías y sistemas operativos.
  • Usted debe tener experiencia profesional como (o el entrenamiento para ser) un profesional de nivel empresarial en Linux (incluyendo experiencia como parte de otra responsabilidad).
  • Usted debe tener conocimientos avanzados y de nivel empresarial en administración de Linux, incluyendo instalación, gestión, seguridad, resolución de problemas y mantenimiento.
  • Usted debe estar capacitado para usar herramientas de fuente abierta para medir la planificación de capacidad y resolver problemas de recursos.
  • Usted debe contar con experiencia profesional en el uso de LDAP integrado con servicios UNIX® y servicios de Microsoft® Windows®, incluyendo Samba, Pluggable Authentication Modules (PAM), e-mail y Active Directory.
  • Usted debe estar capacitado para planificar, desarrollar la arquitectura, diseñar e implementar un entorno completo utilizando Samba y LDAP, así como medir la planificación de capacidad y la seguridad de los servicios.
  • Usted debe estar capacitado para crear scripts en Bash o Perl o tener conocimientos de al menos un lenguaje de programación de sistemas (por ejemplo, lenguaje C).

Para continuar con la preparación para el nivel 3 de certificación, ver los instructivos de la serie de developerWorks para el examen 301 del LPI, así como el conjunto completo de instructivos LPI de developerWorks.

El Linux Professional Institute no endosa a terceros ningún material ni técnicas de preparación de exámenes en particular.

Acerca de este instructivo

Bienvenido a "Planificación de capacidad", el último de los seis instructivos diseñados para prepararlo para el examen 301 del LPI. En este instructivo, usted aprenderá todo sobre la medición de recursos UNIX, el análisis de requisitos y la predicción de futuros requisitos de recursos.

Este instructivo está organizado según los objetivos del LPI para este tema. En general, durante el examen usted debería esperar más preguntas sobre aquellos objetivos de mayor peso.

Objetivos

La Tabla 2 muestra un detalle de los objetivos para este instructivo.

Tabla 2. Planificación de capacidad: Objetivos del examen cubiertos en este instructivo
Objetivo del examen del LPIPeso del objetivoResumen del objetivo
306.1
Medir el uso de recursos
4Medir el uso de hardware y de la red.
306.2
Solucionar problemas de recursos
4Identificar y solucionar problemas de recursos.
306.3
Analizar la demanda
2Identificar las demandas de capacidad de su software.
306.4
Predecir futuras necesidades de recursos
1Planificar a futuro sobre la base de la tendencia del uso, y predecir cuándo sus aplicaciones necesitarán más recursos.

Requisitos previos

Para aprovechar al máximo este instructivo, usted debería tener un conocimiento avanzado de Linux y un sistema Linux en funcionamiento para poder practicar los comandos que se tratarán.

Si su manejo de Linux no es lo suficientemente avanzado, quizá primero le convenga revisar los instructivos para exámenes LPIC-1 y LPIC-2.

Las diferentes versiones de un programa pueden proporcionar datos de salida en distinto formato, de manera que sus resultados podrían no ser idénticos a los listados y figuras de este instructivo.

Requisitos de sistema

Para poder seguir los ejemplos que se detallan en estos instructivos, usted necesitará una estación de trabajo Linux con el paquete de software OpenLDAP y soporte para PAM. La mayoría de las distribuciones modernas satisfacen estos requisitos.


Medir el uso de recursos

Esta sección abarca el material para el tema 306.1 del examen 301 correspondiente al Nivel Senior del Linux Professional (LPIC-3). Este tema tiene un peso de 4.

En esta sección, aprenda a:

  • Medir el uso de la CPU
  • Medir el uso de memoria
  • Medir I/O al disco
  • Medir I/O a la red
  • Medir el rendimiento de la firewall y del enrutamiento
  • Mapear el uso de los anchos de banda de clientes

Las computadoras se apoyan en sus recursos de hardware: la unidad central de procesamiento (CPU), la memoria, el disco y la red. Estos recursos se miden para tener una idea del desempeño de la computadora en un determinado momento y dónde pueden acechar problemas. El observar estas mediciones durante cierto tiempo, por ejemplo unos pocos meses, proporciona un historial interesante. A menudo es posible extrapolar estas lecturas a futuro, con lo cual puede predecirse cuándo alguno de los recursos se agotará. Alternativamente, usted puede desarrollar un modelo matemático de su sistema, utilizando información histórica para validarlo, y luego usar este modelo para predecir con mayor exactitud el uso futuro.

Los servidores siempre requieren más de un recurso de hardware para completar una tarea. Una tarea puede requerir el acceso al disco para recuperar datos, y requerir memoria para almacenarlos mientras son procesados por la CPU. Si alguno de los recursos es limitado, el rendimiento se ve perjudicado. La CPU no puede procesar información hasta que ésta no es leída del disco, y la información no puede ser almacenada si la memoria está llena. Estos conceptos están relacionados entre sí. A medida que la memoria se va llenando, el sistema operativo comienza a transferir otra memoria al disco. La memoria también es tomada de los buffers, que se usan para acelerar la actividad del disco.

Comprendiendo los recursos

Para que las mediciones resulten útiles, usted debe comprender qué es lo que está midiendo. Recién entonces puede comenzar a extraer información útil sobre su sistema: información actual, información histórica o predicciones futuras.

CPU

La CPU de la computadora realiza todos los cálculos que necesita una aplicación, hace que los comandos sean expedidos a discos y otros periféricos, y se ocupa de la ejecución del núcleo del sistema operativo. En la CPU se ejecuta sólo una tarea a la vez, ya sea que se trate de ejecutar el núcleo del sistema operativo o una simple aplicación. La tarea en ejecución puede ser interrumpida por una señal de hardware llamada interrupt. Las señales interrupt se disparan a partir de eventos externos tales como un packet de red que se recibe, o por eventos internos tales como el reloj del sistema (llamado tick en Linux). Cuando tiene lugar una señal interrupt, se suspende el proceso activo y se ejecuta una rutina para determinar qué debería hacer el sistema a continuación.

Cuando el proceso en ejecución ha excedido el tiempo que tenía asignado, el núcleo puede cambiarlo por otro proceso empleando un procedimiento llamado context switch. Un proceso puede ser finalizado antes del tiempo asignado si dicho proceso emite un comando I/O cualquiera, tal como leer del disco. La computadora es tanto más rápida que el disco, que la CPU puede ejecutar otras tareas mientras espera que vuelva la solicitud de disco del proceso suspendido.

Cuando hablamos de la CPU de un sistema Linux, debemos tener en cuenta varios factores. El primero es el porcentaje de tiempo que la CPU está ociosa en relación al tiempo que está trabajando (en realidad, la CPU siempre está haciendo algo—se considera en estado ocioso cuando no hay tareas esperando ser ejecutadas). La CPU está operando al máximo cuando el porcentaje de tiempo ocioso es cero. La parte no ociosa de la CPU está dividida en un tiempo de sistema y un tiempo de usuario, donde tiempo de sistema se refiere al tiempo empleado en el núcleo del sistema operativo, y el tiempo de usuario es aquél empleado en trabajos requeridos por el usuario. El tiempo ocioso se divide en el tiempo en que el núcleo se encuentra ocioso porque no tiene nada que hacer, y el tiempo en que está ocioso porque está esperando cierta cantidad de I/O.

Medir estos parámetros es difícil porque para obtener un número preciso se requeriría que la CPU invirtiera todo su tiempo en determinar lo que está haciendo! El núcleo controla el estado actual (sistema, usuario, iowait, tiempo ocioso) alrededor de 100 veces por segundo, y utiliza estas mediciones para calcular los porcentajes.

Otra métrica empleada por Linux para informar el uso de la CPU es el promedio de carga. Esta métrica no está ligada directamente a la utilización de la CPU sino que representa la ponderación exponencial del número de tareas en la lista de espera de ejecución del núcleo durante el último minuto, 5 minutos y 15 minutos. Esta métrica se investiga con mayor detenimiento más adelante.

Otros aspectos a considerar acerca del núcleo son la carga de señales interrupt y los conmutadores de contexto. No hay un límite superior para su número, pero cuantas más señales interrupt y conmutadores de contexto se lleven a cabo, menor será el tiempo que tendrá la CPU para hacer el trabajo del usuario.

Memoria

El sistema tiene dos tipos de memoria: memoria real y espacio de intercambio. La memoria real se refiere a los módulos de RAM en la placa madre. El espacio de intercambio es un lugar de retención temporaria que se usa cuando el sistema intenta asignar más RAM de la que existe físicamente. En esta situación, se pasan páginas de RAM al disco para liberar espacio para la asignación actual. Los datos vuelven a pasarse a la RAM cuando se necesitan de nuevo.

La RAM puede ser utilizada por aplicaciones, por el sistema o puede no ser utilizada. El sistema emplea la RAM de dos maneras: como un buffer para bloques de disco en bruto (entrantes o salientes) y como cache de archivos. El tamaño de los buffers y del cache es dinámico, de manera que la memoria puede ser devuelta a las aplicaciones en caso de ser necesario. Es por este motivo que la mayoría de la gente ve que sus sistemas Linux parecieran no tener memoria libre: el sistema ha asignado la memoria no utilizada para buffers y cache.

La memoria de intercambio reside en el disco. Si hay mucho intercambio se hace más lento el funcionamiento, y esto es un signo de que el sistema agotó su RAM.

Disco

El disco es donde se almacenan datos a largo plazo, por ejemplo un disco duro, un disco flash o una cinta (colectivamente conocidos como dispositivos en bloque). Una excepción es un disco RAM, el cual se comporta como un dispositivo en bloque pero reside en la RAM; estos datos desaparecen cuando se apaga el sistema. La forma más usual de disco es el disco duro, así que la discusión sobre discos en este instructivo está enfocada en este tipo de medio.

Para describir el disco se emplean dos categorías de mediciones: espacio y velocidad. El espacio libre de un disco de refiere al número de bytes del disco que están disponibles para su uso. La sobrecarga de un disco incluye cualquier espacio usado por el sistema de archivos o que no está disponible para usar. Téngase presente que la mayoría de los fabricantes describen los discos en términos de gigabytes de 1.000.000.000 bytes, mientras que los sistemas operativos utilizan el valor en base 2 de 1.073.741.824; esto da como resultado una "pérdida" del 93% para el consumidor. Esto no es sobrecarga pero, si no se tiene en cuenta, los cálculos serán incorrectos.

La segunda métrica de un disco es la velocidad, que mide la velocidad con que los datos regresan al disco. Cuando la CPU emite una solicitud, son varias las cosas que deben darse juntas para que los datos vuelvan a la CPU:

  1. El núcleo coloca la solicitud en una lista de espera, donde aguarda que su turno sea enviado al disco (tiempo de espera).
  2. El comando es enviado al controlador del disco.
  3. El disco busca los cabezales en el bloque requerido (tiempo de búsqueda).
  4. Los cabezales leen los datos del disco.
  5. Los datos son regresados a la CPU.

Cada uno de estos pasos se mide en forma distinta, o a veces no se mide. El tiempo de servicio incluye los últimos tres pasos y representa el tiempo que toma una solicitud en ser atendida a partir del momento en que fue emitida. El tiempo de espera representa todo el procedimiento, e incluye el tiempo en la lista de espera y el tiempo de servicio.

Cierta optimización llevada a cabo por el núcleo consiste en reordenar y combinar solicitudes en la lista de espera del paso 1 para minimizar el número de búsquedas del disco. Esto se denomina elevador, y a través de los años se han utilizado varios algoritmos diferentes.

La red

Linux desempeña dos amplios roles con respecto a la red: el rol de cliente, donde los packets son enviados y recibidos por aplicaciones en el servidor; y el rol de enrutador (o firewall, o puente). Los packets se reciben por una interfaz y se envían por otra (quizás luego de cierto filtrado o cierta inspección).

Generalmente las redes se miden en bits por segundo (o kilobits, megabits o gigabits) y en packets por segundo. Medir los packets por segundo suele ser menos útil, ya que las computadoras tienen una sobrecarga fija por packet, lo cual da como resultado un menor rendimiento con packets de pequeño tamaño. No confunda la velocidad de la placa de red (100Mbit/seg, o gigabit) con la velocidad esperada para la transferencia de datos de o a través de la máquina. Son varios los factores externos que entran en juego, tales como la latencia, el lado remoto de la conexión, y el ajuste del servidor.

Listas de espera

Las listas de espera no son del todo comparables con los otros recursos, pero aparecen con tanta frecuencia en el monitoreo del rendimiento, que deben mencionarse. Una lista de espera es una "cola" en la cual las solicitudes aguardan hasta ser procesadas. El núcleo utiliza listas de espera de distinta manera, desde la lista de espera de ejecución, que contiene la lista de procesos a ser ejecutados, hasta listas de espera de discos, de red y de hardware. Generalmente, una lista de espera se refiere a un lugar en la memoria que el núcleo utiliza para seguir los pasos de un conjunto particular de tareas, pero también puede referirse a una porción de memoria en un componente de harware que administrada por el hardware.

Las listas de espera aparecen de dos formas en el ajuste del rendimiento. Primero, cuando en una lista de espera ingresa demasiado trabajo, cualquier nuevo trabajo se pierde. Por ejemplo, si en una interfaz de red ingresan demasiados packets, algunos se caen (en los círculos de redes, esto se llama caída de cola). Segundo, si una lista de espera se usa excesivamente (o, a veces, no lo suficiente), entonces hay otro componente que no está funcionando como debiera. Si en la lista de espera de ejecución hay con frecuencia un gran número de procesos, esto puede significar que la CPU está sobrecargada.

Medir el rendimiento

En el paquete Linux hay varias herramientas disponibles para medir el rendimiento. Algunas de estas herramientas miden la CPU, el disco, la memoria y la red directamente; otras muestran indicadores, tales como el uso de listas de espera, la creación de procesos y errores. Algunas herramientas muestran valores instantáneos, y otras muestran valores que han sido promediados a lo largo de cierto tiempo. Es igualmente importante comprender cómo se tomó la medición y qué es lo que se está midiendo.

vmstat

vmstat es una herramienta útil para mostrar las métricas de rendimiento usadas más frecuentemente en tiempo real. Lo más importante que hay que comprender sobre vmstat es que el primer resultado que produce representa el promedio de los valores a partir del momento en que el sistema fue iniciado, el cual generalmente debe ser ignorado. Especifique un tiempo de repetición (en segundos) en la línea de comando para que vmstat reporte repetidamente la información empleando los datos actuales. El Listado 1 muestra el resultado de vmstat 5.

Listado 1. Resultado de vmstat 5
# vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  3  17780  10304  18108 586076    0    0  2779   332    1    1  3  4 76 17  0
 1  2  17780  10088  19796 556172    0    0  7803  3940 2257 4093 25 28 14 34  0
 0  2  17780   9568  19848 577496    0    0 18060  1217 1610  910  0  3 48 49  0
 0  0  17780  51696  20804 582396    0    0  9237  3490 1736  839  0  3 55 41  0

El Listado 1 muestra el resultado del comando vmstat con mediciones tomadas cada 5 segundos. La primera línea de valores representa el promedio a partir del momento en que se inició el sistema, por lo que debe ser ignorada. Las dos primeras columnas se refieren a procesos. El número debajo del encabezado r es el número de procesos en la lista de espera de ejecución al momento de la medición. Los procesos en la lista de espera de ejecución están aguardando en la CPU. La siguiente columna es el número de procesos bloqueados en I/O, lo cual significa que están durmiendo hasta que retorne alguna porción de I/O, y no pueden ser interrumpidos.

Las columnas debajo del encabezado memory son mediciones instantáneas sobre la memoria del sistema y están expresadas en kilobytes (1024 bytes). swpd es la cantidad de memoria que ha sido transferida al disco. free es la cantidad de memoria libre que no es usada por las aplicaciones, los buffers o el cache. No se sorprenda si este número es bajo (ver la explicación de free para mayor información acerca de qué es realmente la memoria libre). buff y cache indican la cantidad de memoria dedicada a buffers y cache. Los buffers almacenan bloques de disco en bruto, y el cache almacena archivos.

Las primeras dos categorías son mediciones instantáneas. Es posible que durante un breve tiempo toda la memoria libre se consuma pero vuelva antes del siguiente intervalo. El resto de los valores son promedios a lo largo del periodo de muestreo.

swap es la cantidad promedio de memoria transferida desde el disco (si) y hacia el disco (so) por segundo; se reporta en kilobytes. io es el número de bloques de discos por segundo que se leen de todos los dispositivos de bloque y se envían a los dispositivos de bloque.

La categoría system describe el número de señales interrupt por segundo (in) y de conmutadores de contexto (cs) por segundo. Las señales interrupt provienen de dispositivos (como por ejemplo una placa de red enviándole una señal al núcleo para indicarle que hay un packet aguardando) y del temporizador del sistema. En algunos núcleos, el temporizador del sistema dispara 1.000 veces por segundo, así que este número puede ser bastante elevado.

La última categoría de mediciones muestra lo que sucede con la CPU, reportado como porcentaje del tiempo total de la CPU. Estos cinco valores deben sumar 100. us es el tiempo promedio que la CPU empleó en tareas del usuario a lo largo del periodo de muestreo, y sy es el tiempo promedio que la CPU empleó en tareas del sistema. id es el tiempo que la CPU estuvo ociosa, y wa es el tiempo que la CPU estuvo esperando I/O (el Listado 1 fue tomado de un sistema muy cargado de I/O; puede verse que 34-49% del tiempo de la CPU se emplea en aguardar que los datos retornen del disco). El valor final, st (el tiempo de robo), es para servidores que están ejecutando un hipervisor y máquinas virtuales. Se refiere al porcentaje de tiempo que el hipervisor podría haber estado ejecutando una máquina virtual pero tenía otra cosa para hacer.

Como puede verse en el Listado 1, vmstat proporciona una gran cantidad de información sobre una amplia variedad de métricas. Si está ocurriendo algo mientras uno está conectado al sistema, vmstat es una excelente manera de estrechar el origen.

vmstat también puede mostrar información interesante sobre el uso del disco por dispositivo, lo cual puede echar más luz sobre las categorías de io e intercambio del Listado 1. El parámetro -d informa algunas estadísticas de disco, tales como el número total de lecturas y escrituras por disco. El Listado 2 muestra parte de los resultados de vmstat -d 5 (luego de filtrar los dispositivos no utilizados).

Listado 2. Utilización de vmstat para mostrar el uso del disco
disk- ------------reads------------ ------------writes----------- -----IO------
       total merged sectors      ms  total merged sectors      ms    cur    sec
hda   186212  28646 3721794  737428 246503 4549745 38981340 8456728      0   2583
hdd   181471  27062 3582080  789856 246450 4549829 38981624 8855516      0   2652

Cada disco se muestra en una línea aparte, y los resultados se dividen en lecturas y escrituras. Las lecturas y escrituras, a su vez, luego se dividen en el número total de solicitudes emitidas, cuántas solicitudes se combinaron en el elevador del disco, el número de sectores de los cuales se leyó o a los cuales se escribió, y el tiempo total de servicio. Todos estos números corresponden a contadores, de manera que aumentarán hasta el próximo reinicio del sistema, contrariamente a los valores promediados cuando son considerados sin la opción -d.

El último grupo de mediciones del Listado 2, debajo del encabezado IO, muestra el número actual de operaciones I/O en curso para el disco y el número total de segundos empleados en I/O a partir del momento en que se inició el sistema.

El Listado 2 muestra que el volumen de lectura es similar para los dos discos, y que el volumen de escritura es casi idéntico. Sucede que estos dos discos constituyen un espejo de software, así que éste es el comportamiento esperado. La información del Listado 2 puede estar indicando discos más lentos o discos con más uso que otros.

iostat

Íntimamente relacionado al ejemplo de vmstat -d del Listado 2, está el comando iostat. Este comando proporciona detalles sobre el uso del disco por dispositivo. iostat es mejor que vmstat -d porque brinda más detalles. Al igual que con vmstat, puede introducirse un número en iostat que indica el intervalo de actualización. Asimismo, como en vmstat, el primer resultado representa los valores a partir del momento en que el sistema fue iniciado, y por lo tanto generalmente es ignorado. El Listado 3 muestra el resultado de iostat con intervalos de 5 segundos.

Listado 3. Resultado del comando iostat
$ iostat 5
Linux 26.20-1.3002.fc6xen (bob.ertw.com)       02/08/2008

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.85    0.13    0.35    0.75    0.01   97.90

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
hda               1.86        15.24       13351    4740568   41539964
hdd               1.85        14.69       133.51    4570088   41540256

La primera parte de cada intervalo de medición muestra el uso de la CPU, como también lo muestra vmstat. Sin embargo, aquí se presentan dos decimales. La segunda parte del resultado muestra a todos los dispositivos de bloque en el sistema (para limitar el número de dispositivos que se muestra, deben pasarse los nombres de los dispositivos en la línea de comando, como por ejemplo iostat 5 hda sda). La primera columna, tps, representa las transferencias por segundo al dispositivo luego de que las solicitudes han sido combinadas por el elevador. El tamaño de las transferencias no está especificado. Las últimas cuatro columnas se refieren a bloques de 512 bytes y muestra los bloques leídos por segundo, escritos por segundo, el total de bloques leídos, y el total de bloques escritos, respectivamente. Si los valores estuvieran reportados en kilobytes o megabytes, debe usarse -k o -m, respectivamente. La opción -p expone detalles al nivel de partición, en caso de que puedan necesitarse tales datos.

Puede obtenerse mucha más información si se usa el parámetro -x, que se muestra en el Listado 4. El Listado 4 también limita el resultado a un drive. El formato se ajustó para adecuarlo a los límites del ancho de página.

Listado 4. Información ampliada de iostat
# iostat -x 5 hda
..... CPU information removed ...
Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz 
hda           16669.31     1.49 756.93  1.49 139287.13    27.72   18369
                avgqu-sz   await  svctm  %util
                    1.58    208   1.28  96.83

Los primeros seis valores se refieren a lecturas y escrituras por segundo. rrqm/s y wrqm/s se refieren a número de solicitudes de lectura y escritura que fueron combinadas. En contraste, r/s y w/s representan el número de lecturas y escrituras enviadas al disco. Por lo tanto, el porcentaje de solicitudes de disco combinadas es 16669 / (16669 + 757) = 95%. rsec/s y wsec/s indican la tasa de lectura y escritura en sectores por segundo.

Las siguientes cuatro columnas muestran información sobre listas de espera y tiempos del disco. avgrq-sz es el tamaño promedio de las solicitudes emitidas hacia el dispositivo (en sectores). avgqu-sz es la longitud promedio de la lista de espera del disco a lo largo del intervalo de medición. El await es el tiempo promedio de espera (en milisegundos), que representa el tiempo promedio que emplea una solicitud desde que es enviada al núcleo hasta el momento en que es devuelta. svctm es el tiempo promedio de servicio (en milisegundos), que es el tiempo que emplea una solicitud de disco desde que sale de las listas de espera y es enviada al disco hasta el momento en que es devuelta.

El valor final, %util, es el porcentaje de tiempo que el sistema estuvo llevando a cabo I/O en ese dispositivo, y también es conocido como saturación. El 96.83% reportado en el Listado 4 indica que el disco estaba casi a su capacidad durante ese tiempo.

mpstat

mpstat reporta información detallada sobre la CPU (o sobre todas las CPUs en una máquina multiprocesador). Gran parte de esta información es reportada por iostat y vmstat de alguna forma, pero mpstat proporciona datos para todos los procesadores por separado. El Listado 5 muestra a mpstat con intervalos de medición de 5 segundos. A diferencia de lo que sucede con iostat y vmstat, aquí no debe ignorarse la primera línea.

Listado 5. Información sobre la CPU desplegada con mpstat
# mpstat -P 0 5
Linux 2.620-1.3002.fc6xen (bob.ertw.com)       02/09/2008

09:45:23 PM  CPU   %user   %nice    %sys %iowait   %irq  %soft  %steal   %idle   intr/s
09:45:25 PM    0   77.61   21.89    0.00    0.00   0.50   0.00    0.00    0.00   155.22
09:45:27 PM    0   68.16   30.85    1.00    0.00   0.00   0.00    0.00    0.00   154.73

El agregado de -P 0 especifica que debe mostrarse la primera CPU (comenzando en 0). También puede especificarse -P ALL para todas las CPUs por separado. Los campos devueltos por mpstat son los siguientes:

  • %user: El porcentaje de tiempo empleado en tareas de usuario, excluyendo las tareas "nice"
  • %nice: El porcentaje de tiempo empleado en tareas de usuario "nice" (de menor prioridad)
  • %sys: El porcentaje de tiempo empleado en tareas del núcleo
  • %iowait: El porcentaje de tiempo empleado en esperar I/O mientras está en estado ocioso
  • %irq: El porcentaje de tiempo atendiendo interrupciones de hardware
  • %soft: El porcentaje de tiempo empleado en interrupciones de software
  • %steal: El porcentaje de tiempo que el hipervisor robó de una máquina virtual
  • intr/s: El número promedio de señales de interrupción por segundo

pstree

Comprender cuáles procesos generaron otro proceso resulta útil cuando uno está rastreando el uso de recursos. Una forma de averiguar esto es utilizando los resultados de ps -ef y usar el identificador parental de procesos para abrirse camino de regreso a PID 1 (init). También puede emplearse ps -efjH, que ordena los resultados en un árbol padre-hijo, e incluir el tiempo de uso de la CPU.

Una utilidad llamada pstree imprime el árbol de procesos en un formato más gráfico y también agrupa múltiples instancias del mismo proceso en una línea. El Listado 6 muestra los resultados de pstree luego de haber pasado el PID del Postfix daemon.

Listado 6. Resultados del pstree
[root@sergeant ~]# pstree 7988
master─┬─anvil
       ├─cleanup
       ├─local
       ├─pickup
       ├─proxymap
       ├─qmgr
       ├─2*[smtpd]
       └─2*[trivial-rewrite]

El proceso principal, denominado master, ha originado varios otros procesos, tales como anvil, cleanup y local. Las dos últimas líneas del resultado son del formato N*[algo], donde algo es el nombre de un proceso, y N es el número de hijos con ese nombre. Si algo está entre llaves ({}) además de estar entre corchetes ([]), eso indicaría N flujos de ejecución (por lo general, ps no muestra flujos de ejecución, a menos que se use -L).

w, uptime, top

Estas utilidades se presentan agrupadas porque son las primeras que la gente tiende a utilizar cuando investiga un problema. El Listado 7 muestra los resultados del comando w.

Listado 7. Resultados del comando w
# w
 12:14:15 up 33 days, 15:09,  2 users,  load average: 0.06, 0.12, 0.09
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty2     -                17Jan08 18days  0.29s  0.04s login -- root     
root     pts/0    bob              Sat22    0.00s  0.57s  0.56s -bash

La primera línea de w proporciona la mayor parte de la información. La primera parte, "12:14:15 up 33 days, 15:09" informa la hora actual, seguida del tiempo de operación de 33 días, 15 horas y 9 minutos. La segunda parte, "2 users", informa el número de usuarios conectados. La parte final es el promedio de carga, expresado como el promedio para 1 minuto, 5 minutos y 15 minutos.

El promedio de carga es el promedio ponderado del número de procesos en la lista de espera de ejecución a lo largo de un cierto lapso. Cuanto más alto es el promedio de carga, mayor es el número de procesos que procuran competir por las CPUs. Los promedios de carga no están normalizados al número de CPUs, lo cual significa que el promedio de carga y el número de CPUs no están relacionados.

Para poder utilizar el promedio de carga debe comprenderse la ponderación. El promedio de carga se actualiza cada 5 segundos, y la información más antigua juega un rol menos importante en el cálculo. Si un sistema pasara inmediatamente de tener 0 procesos en la lista de espera de ejecución a tener 1 proceso, el gráfico del promedio de carga de 1 minuto a lo largo del minuto siguiente no sería una línea recta sino una curva que al principio aumenta rápidamente y luego disminuye hasta la marca de 60 segundos. Para un mayor detalle acerca de cómo se calcula el promedio de carga, véase la sección Recursos.

La aplicación práctica de ponderar el promedio de carga consiste en que las variaciones de la carga real al momento de la medición se suavizan, pero el estado actual se refleja más en los números, especialmente en el promedio de 1 minuto.

Luego de la primera línea viene una lista de usuarios conectados, incluyendo la duración de su conexión, su ubicación, e información sobre el uso de la CPU. El primer usuario, raíz, está conectado desde tty2 (una consola local) y ha estado ocioso durante 18 días. El segundo usuario nuevamente es raíz, pero está conectado por la red y actualmente en la shell. Las columnas JCPU y PCPU dan una idea de cuánto tiempo de CPU ha utilizado el usuario; la primera columna incluye trabajos en el pasado, mientras que PCPU es para el proceso actualmente en uso por el usuario.

Los resultados de uptime muestran exactamente la misma primera línea de w pero ninguna información sobre los usuarios. En términos prácticos, w es la más útil de las dos porque brinda más información sobre los usuarios y porque es más corta para escribir!

Otro comando muy empleado es top, que muestra una lista permanentemente actualizada de los procesos más importantes (ordenados por uso de CPU o memoria), además de algunas otras métricas. La Figura 1 muestra una captura de pantalla de top en acción.

Figura 1. top en acción
top en acción

La primera línea muestra lo mismo que uptime, vale decir el tiempo de operación y el promedio de carga. La segunda línea es el número de procesos. Los procesos running están en la lista de espera de ejecución; los procesos sleeping están esperando que algo los despierte. Un proceso stopped ha sido pausado, posiblemente porque está siendo rastreado o depurado. Un proceso zombie se ha excitado, pero el proceso padre no ha tomado conocimiento de la muerte.

Algo no suma

VIRT = RES + SWAP, lo cual significa que SWAP = VIRT - RES. Observando el PID 13435, vemos que VIRT es 164m y RES es 76m, por lo que SWAP debe ser 88m. Sin embargo, las estadísticas de swap en la parte superior de la pantalla indican que solamente se usan 144K de swap! Esto puede verificarse utilizando la tecla f cuando se está dentro de top y habilitando más campos, como por ejemplo swap.

Tal como resulta, swap significa más que sólo páginas transferidas al disco. El binario y las bibliotecas de una aplicación no necesitan permanecer en memoria todo el tiempo. El núcleo puede marcar algunas páginas de la memoria como innecesarias por el momento; pero puesto que el binario está en una ubicación conocida del disco, no hay necesidad de usar el archivo swap. Aún así, éste es contado como swap porque la parte del código no es residente. Además, la memoria puede ser asignada por la aplicación a un archivo del disco. Dado que el tamaño total de la aplicación (VIRT) incluye la memoria asignada pero ésta no es residente (RES), es contada como swap.

La tercera línea indica el uso de la CPU; por orden vemos: usuario, sistema, procesos "nice", tiempo ocioso, espera de I/O, interrupción de hardware, interrupción de software, y tiempo de robo. Estos números son porcentajes de tiempo en el último intervalo de medición (3 segundos, por default).

Las dos últimas líneas de la sección superior muestran estadísticas de la memoria. La primera brinda información sobre la memoria real; en la Figura 1 puede verse que el sistema tiene 961.780K de RAM (luego de la sobrecarga del núcleo). Ha sido usada toda, salvo 6.728K, con alrededor de 30MB de buffers y 456M de cache (el cache se muestra al final de la segunda línea). La segunda línea muestra el uso del swap: el sistema tiene casi 3G de swap, de la cual sólo hay 144K usados.

El resto de la pantalla presenta información sobre los procesos actualmente en ejecución. top muestra todos los procesos que permite el tamaño de la pantalla. Cada proceso tiene su propia línea, y la lista se actualiza en cada intervalo de medición con las tareas que utilizaron más CPU en los primeros puestos. Las columnas son las siguientes:

  • PID: El identificador del proceso
  • USER: El nombre de usuario efectivo del proceso (si el programa emplea setuid(2) para cambiar el usuario, se muestras el usuario nuevo)
  • PR: La prioridad de la tarea, utilizada por el núcleo para determinar qué proceso alcanza primero a la CPU
  • NI: El nivel "nice" de la tarea, establecido por el administrador del sistema para influenciar la determinación de los procesos que alcanzan primero a la CPU
  • VIRT: El tamaño de la imagen virtual del proceso, que es la suma del espacio usado por la RAM (tamaño residente) y el tamaño de los datos en swap (tamaño swapped)
  • RES: El tamaño residente del proceso, que es la cantidad de RAM real usada por el proceso
  • SHR: La cantidad de memoria compartida por la aplicación, tal como las bibliotecas dinámicas o memoria compartida SysV (*.so)
  • S: El estado; por ejemplo, durmiendo, ejecutándose o zombie
  • %CPU: El porcentaje de CPU utilizado en el último intervalo de medición
  • %MEM: El porcentaje de RAM (excluyendo swap) usado cuando se realizó la última medición
  • TIME+: El tiempo en minutos:segundos:centésimas empleado por el proceso
  • COMMAND: El nombre del comando que se está ejecutando

top proporciona una manera rápida de ver cuáles son los procesos que usan más CPU y además brinda una buena vista en panel de la CPU y la memoria del sistema. Puede ordenarse el resultado de top por el uso de memoria si se escribe M en la pantalla de top.

free

Luego de haber visto top, uno debería comprender free en forma inmediata. El Listado 8 muestra el resultado de free con el uso de la opción -m para reportar todos los valores en megabytes.

Listado 8. Utilizando el comando free
# free -m
             total       used       free     shared    buffers     cached
Mem:           939        904         34          0        107        310
-/+ buffers/cache:        486        452
Swap:         2847          0       2847

free presenta el uso de la memoria en unas pocas direcciones. La primera línea muestra la misma información que vimos para top. La segunda línea representa la memoria usada y libre sin considerar buffers ni cache. En el Listado 8 hay 452M de memoria libre para ser utilizados por una aplicación; esta memoria provendrá de la memoria libre (34M), los buffers (107M) o el cache (310M).

La última línea muestra las mismas estadísticas de swap que top.

Mostrar las estadísticas de la red

Obtener las estadísticas de la red es menos directo que para la CPU, la memoria y el disk. El método primordial consiste en leer los contadores de /proc/net/dev, lo cual reporta las transferencias por interfaz en packets y en bytes. Si se desea un valor por segundo, debe calcularlo uno mismo dividiendo la diferencia entre dos medidas sucesivas por el intervalo. En forma alternativa, puede usarse una herramienta como bwm para automatizar la recolección y presentación del ancho de banda total. La Figura 2 muestra a bwm en acción.

Figura 2. Utilizando el comando bwm
Utilizando el comando bwm

bwm muestra el uso de la interfaz de distintas maneras. La Figura 2 muestra la tasa instantánea cada medio segundo, aunque también pueden obtenerse promedios de 30 segundos, el ancho de banda máximo y el recuento de bytes. En la Figura 2 puede verse que eth0 está recibiendo alrededor de 20K/seg de tráfico, el cual parece provenir de vif0.0. Si lo que una busca no es el número de bytes por segundo, puede cambiarse por bits, packets y errores, con la tecla u.

Para obtener más detalles acerca de cuáles son los hosts responsables del tráfico, se necesita iftop, que brinda una interfaz de tipo top para el tráfico de red. El núcleo no proporciona esta información en forma directa, así que iftop emplea la biblioteca pcap para inspeccionar los packets en el cable, lo cual requiere privilegios de raíz. La Figura 3 muestra iftop en acción cuando está acoplada al dispositivo eth2.

Figura 3. Resultado de iftop -i eth2
Resultado de iftop -i eth2

iftop muestra los máximos conversadores de la red. Por default, cada conversación conlleva dos líneas: una para la mitad que se envía y la otra para la mitad que se recibe. Si observamos la primera conversación de mybox a pub1.kernel.org, la fila superior muestra el tráfico enviado de mybox, y la segunda línea muestra el tráfico recibido por mybox. Los números a la derecha indican el tráfico promedio en los últimos 2 segundos, 10 segundos y 40 segundos, respectivamente. También se puede ver una barra negra superpuesta a los hostnames, lo cual es una indicación visual del promedio de 10 segundos (la escala se muestra en la parte superior de la pantalla).

Si observamos la Figura 3 con más detenimiento, la primera transferencia probablemente sea una descarga, dada la gran cantidad de tráfico recibido (un promedio de alrededor de medio megabit por segundo durante los últimos 10 segundos) en comparación con la pequeña cantidad de tráfico enviado. El segundo conversador tiene una cantidad igual de tráfico que ha permanecido relativamente estable alrededor de 75-78k/sec. Esta es una llamada de voz G.711 a través de les.net, el proveedor de VoIP. La tercera transferencia muestra una descarga de 128K con una pequeña carga: se trata de un flujo de radio por Internet.

La elección de la interfaz a la que uno se acopla es importante. La Figura 3 usa la interfaz exterior en una firewall que ve todos los packets una vez que han pasado a través del enmascaramiento de IP. Esto provoca que se pierda la dirección interna. Usar una interfaz diferente, por ejemplo una interfaz interna, preservaría esta información.

sar

sar es tema de un artículo completo (ver la sección Recursos). sar mide docenas de métricas importantes cada 10 minutos y proporciona un método para recuperar las mediciones. Para determinar "lo que está sucediendo ahora" pueden usarse las herramientas precedentes; sar informa sobre "lo que sucedió esta semana". Adviértase que sar purga sus datos para conservar solamente los últimos 7 días de datos.

La recolección de datos debe configurarse añadiendo dos líneas a la crontab de la raíz. El Listado 9 muestra una crontab típica para sar.

Listado 9. Crontab de la raíz para la recolección de datos sar
# Collect measurements at 10-minute intervals
0,10,20,30,40,50   * * * *   /usr/lib/sa/sa1 -d 1 1
# Create daily reports and purge old files
0                  0 * * *   /usr/lib/sa/sa2 -A

La primera línea ejecuta el comando sa1 para recolectar datos cada 10 minutos; este comando ejecuta sadc para llevar a cabo la recolección real. Este trabajo es auto-contenido: sabe a qué archivo escribir y no requiere otra configuración. La segunda línea invoca a sa2 a medianoche para purgar los archivos de datos más antiguos y recolectar los datos del día en un archivo de texto legible.

Conviene chequear para ver si el sistema ejecuta sar antes de confiar en los datos. Algunos sistemas deshabilitan la recolección de estadísticas de disco; para arreglar esto, debe añadirse -d a la llamada de sa1 (El Listado 9 tiene esta añadidura).

Habiendo recolectado algunos datos, ahora puede ejecutarse sar sin ninguna opción para ver el uso de la CPU del día. El Listado 10 muestra parte del resultado.

Listado 10. Ejemplo de resultado de sar
[root@bob cron.d]# sar | head
Linux 2.6.20-1.3002.fc6xen (bob.ertw.com)       02/11/2008

12:00:01 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
12:10:01 AM       all      0.18      0.00      0.18      3.67      0.01     95.97
12:20:01 AM       all      0.08      0.00      0.04      0.02      0.01     99.85
12:30:01 AM       all      0.11      0.00      0.03      0.02      0.01     99.82
12:40:01 AM       all      0.12      0.00      0.02      0.02      0.01     99.83
12:50:01 AM       all      0.11      0.00      0.03      0.05      0.01     99.81
01:00:01 AM       all      0.12      0.00      0.02      0.02      0.01     99.83
01:10:01 AM       all      0.11      0.00      0.02      0.03      0.01     99.83

Los números que se muestran en el Listado 10 deberían resultar familiares a esta altura: son los diferentes contadores de la CPU que muestra top, vmstat y mpstat. Utilizando uno o más parámetros de las líneas de comandos que se muestran en la Tabla 3, puede visualizarse mucha más información.

Tabla 3. Sinopsis de las opciones de sar
OpciónEjemploDescripción
-Asar -AMuestra todo. A menos que este resultado se esté volcando a un archivo de texto, probablemente no sea necesario. Y si se necesita, este proceso de cualquier manera se ejecuta por la noche como parte de sa2.
-bsar -bMuestra transacciones y bloques enviados a (y leídos desde) dispositivos de bloque, en forma muy similar a iostat.
-Bsar -BMuestra estadísticas de paginación (swap) como las reportadas por vmstat.
-dsar -dMuestra la actividad del disco en forma similar a iostat -x, la cual incluye los tiempos de espera y de servicio y la longitud de la lista de espera.
-nsar -n DEV or sar -n NFSMuestra la actividad de la interfaz (como bwm) cuando se emplea DEV, o las estadísticas de los clientes NFS cuando se emplea la contraseña NFS (para las estadísticas del daemon del servidor NFS, use la contraseña NFSD). La contraseña EDEV muestra información de errores de las tarjetas de red.
-qsar -qMuestra información sobre el tamaño de la lista de espera de ejecución y la lista total de procesos, y los promedios de carga, tal como los reportados por vmstat y uptime.
-rsar -rMuestra información acerca del uso de la memoria, swap, cache y buffer (como free).
-fsar -f /var/log/sa/sa11Lee información a partir de un archivo distinto. Los nombres de los archivos responden al día del mes.
-ssar -s 08:59:00Comienza a brindar información al momento de la primera medición luego de un tiempo dado. Si se especifica 09:00:00, la primera medición será a 09:10, de manera que debe restarse un minuto al tiempo deseado.
-esar -e 10:01:00Especifica el punto de corte para la presentación de las mediciones. Debe sumarse un minuto al tiempo deseado para asegurarse de obtenerlo.

También pueden combinarse varios parámetros para obtener más de un informe, o un archivo distinto con un tiempo de inicio y uno de finalización.

df

Los discos duros son un recurso finito. Si una partición se queda sin espacio, habrá problemas. El comando df muestra la situación referente al espacio del disco. El Listado 11 muestra el resultado de df -h, que fuerza al resultado a estar en un formato más amigable.

Listado 11. Verificando el uso del espacio del disco con df -h
$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      225G  169G   44G  80% /
/dev/hda1              99M   30M   64M  32% /boot
tmpfs                 474M     0  474M   0% /dev/shm

El Listado 11 muestra un sistema de un único archivo en la raíz, que tiene 225G de tamaño, con 44G libres. La partición /boot tiene 99M con 64M libres. tmpfs es un sistema especial de archivos, y no se refiere a ningún dispositivo en particular. Si una partición está llena, no se aprecia espacio disponible y el uso es del 100%.


Solucionar problemas de recursos

Esta sección abarca material para el tema 306.2 del examen 301 correspondiente al Nivel Senior del Linux Professional (LPIC-3). Este tema tiene un peso de 4.

En esta sección aprenda como:

  • Parear/correlacionar los síntomas del sistema con posibles problemas
  • Identificar los cuellos de botella de un sistema

En la sección anterior se mostró cómo presentar diferentes contadores de rendimiento dentro del sistema Linux. Ahora es tiempo de aplicar en su sistema estos comandos para resolver problemas relacionados a recursos.

Metodología para la solución de problemas

Establezca su estrategia para la resolución de problemas antes de introducirse en los detalles de las restricciones de recursos y su sistema. Todas las estrategias para resolver problemas se resumen en cuatro pasos:

  1. Identificar los síntomas.
  2. Determinar la causa raíz.
  3. Implementar un arreglo.
  4. Evaluar los resultados.

Identificar los síntomas

El primer paso para resolver un problema es identificar los síntomas. Un ejemplo de síntoma es cuando el "e-mail está lento" o "me quedé sin espacio en el disco". Los síntomas hacen que los usuarios se quejen, y esos usuarios no estarán felices hasta que los síntomas hayan desaparecido. Sin embargo, no deben confundirse los síntomas con el problema: a menudo, el problema es diferente de lo que reportan los usuarios, aunque el problema está provocando los síntomas.

Una vez identificados los síntomas, intente cuantificar el reclamo y aclarar las condiciones en las que ocurre. Más que el sistema de e-mail que está lento, uno puede darse cuenta que antes los e-mails se recibían pocos segundos después de haber sido enviados, pero ahora demoran horas. Y un usuario que se quedó sin espacio de disco tiene que estar haciendo algo, como por ejemplo guardar un archivo o procesar un trabajo por lotes.

Este último paso de cuantificar el reclamo tiene dos finalidades. La primera es permitir reproducir el problema, lo cual luego ayudará a determinar cuándo éste ha sido resuelto. La segunda finalidad es obtener del usuario más detalles que ayudarán a determinar la causa raíz. Cuando usted advierta que un trabajo que antes tomaba 5 minutos en ser ejecutado ahora toma una hora, podrá preguntarse sobre la naturaleza del trabajo. Esto puede hacerle comprender que el trabajo emplea información de una base de datos u otro servidor que debe ser incluido en el alcance de su búsqueda de la causa raíz.

Determinar la causa raíz

Determinar la causa raíz implica usar los comandos aprendidos en la sección Medir el uso de recursos para hallar la causa del problema. Para esto, deben investigarse los recursos tales como la CPU, la memoria, el disco y la red. Idealmente, mientras el problema está ocurriendo se pueden recolectar datos con herramientas de tiempo real como vmstat, iostat y top. Si no, puede utilizarse algo que produzca información histórica, por ejemplo sar.

Si el problema está relacionado con los recursos, aparecerá uno de dos resultados: uno (o más) de los recursos estará al 100% de su utilización, y la causa debería ser obvia, u obviamente nada está siendo sobreutilizado.

En el segundo caso, deberíamos referirnos a una línea de base. La línea de base es un conjunto de datos de referencia que puede usarse para comparar lo que es "normal" con lo que uno está viendo. La línea de base puede ser una serie de gráficos o de reportes sar archivados que muestran actividad normal. La línea de base también será útil más adelante, cuando veamos cómo predecir el crecimiento.

A medida que uno emplea las herramientas de administración, comienza a desarrollar una imagen de la causa raíz del problema. Podría suceder que el servidor de correo quedó trabado por un mensaje, provocando que se detuviera el procesamiento de los otros mensajes. O quizás un trabajo por lotes está consumiendo toda la CPU del sistema.

A esta altura, debe tenerse cuidado en haber identificado apropiadamente la causa raíz del problema. Una aplicación que genera un enorme logfile puede haber causado el quedarse sin espacio. Si se identifica el logfile como la causa raíz y se decide eliminarlo, la aplicación aún puede llenar el disco en algún momento futuro.

Implementar una reparación

A menudo se dispone de varias maneras de reparar un problema. Tomemos, por ejemplo, un trabajo por lotes que está consumiendo todos los recursos de la CPU. Si se elimina el trabajo, el usuario que está ejecutándolo probablemente lo pierda, si bien los demás usuarios tendrán nuevamente su servidor disponible. Puede reasignarse el nivel "nice" del proceso para darle a los otros procesos más tiempo en la CPU. Generalmente esta es una decisión que depende de cada uno, según las necesidades del negocio y la urgencia de la situación.

Evaluar los resultados

Una vez implementada la solución, debe volverse atrás y ver si se resolvió el problema. ¿Los e-mails se están entregando en forma instantánea? ¿Los usuarios pueden conectarse? Si no es así, entonces debemos regresar y buscar nuevamente la causa raíz, lo cual conducirá a otra reparación que debe ser evaluada. Si la reparación falló, también debe verificarse que las cosas no hayan empeorado!

Luego de que el problema ha sido solucionado, determine si debe tomar acciones a largo plazo. ¿Debe considerarse un disco más grande, o mover el trabajo por lotes de un usuario a otro host? Los procesos sin explicación incitan a realizar un control de seguridad más exhaustivo del servidor para asegurarse de que no ha sido explotado.

Problemas compuestos

Algunos problemas de rendimiento son obvios. Un usuario se queja de que algo está ejecutándose en forma lenta: usted se conecta y dispara top. Advierte que hay un proceso acaparando innecesariamente la CPU: lo elimina, y el sistema vuelve a la normalidad. Luego de bañarlo en alabanzas, su jefe le da un aumento de sueldo y el resto del día libre. (Bueno, quizá la última parte es algo exagerada.)

¿Qué sucede cuando el problema no es obvio? A veces los problemas son causados por más de una cosa, o un síntoma es causado por algo que, en principio, no parece relacionado.

La espiral swap

La memoria es veloz, y probablemente usted dispone de mucha en su sistema. Pero a veces una aplicación necesita más memoria de la que tiene el sistema, o un conjunto de procesos combinados terminan usando más memoria de la que hay disponible. En este caso, se usa la memoria virtual. El núcleo asigna un lugar en el disco y transfiere las páginas de memoria residente al disco para que puedan ser usadas por la aplicación activa. Cuando se necesita la memoria en el disco, se la vuelve a RAM, opcionalmente transfiriendo alguna otra memoria al disco para hacer lugar.

El problema con ese proceso es que el disco es lento. Si uno se sumerge en swap sólo brevemente, puede no darse cuenta. Pero cuando el sistema comienza a transferir memoria al disco más activamente para satisfacer una demanda creciente de memoria, estamos en problemas. Hallaremos que las I/O del disco aumentan incontrolablemente, y parecerá que el sistema no responde. De hecho, el sistema probablemente no responde, ya que las aplicaciones están esperando que su memoria sea transferida del disco a la RAM.

Los admins de UNIX llaman a esto la espiral swap (o a veces, más sombríamente, la espiral swap de la muerte). Finalmente, el sistema llega a detenerse, ya que los discos están operando al límite tratando de transferir memoria hacia y desde ellos. Si el dispositivo swap está en el mismo disco físico que los datos, las cosas empeoran aún más. Una vez que la aplicación alcanza la CPU y emite una solicitud I/O, tiene que esperar más tiempo mientras la actividad swap está siendo atendida.

El obvio síntoma de la espiral swap consiste en esperas absurdamente prolongadas para hacer cualquier cosa, incluso obtener el tiempo activo (uptime). También se ve un elevado promedio de carga, ya que muchos procesos están en la lista de espera de ejecución debido a que el sistema cuenta con copias de seguridad. Para diferenciar entre este problema y uno correspondiente a la alta CPU, puede verificarse con top si los procesos están utilizando la CPU en exceso, o puede verificarse con vmstat si hay mucha actividad swap. Por lo general, la solución consiste en comenzar a eliminar procesos hasta que el sistema vuelva a la normalidad aunque, dependiendo de la naturaleza del problema, quizá sea necesario esperar pacientemente.

Sin espacio en disco

A las aplicaciones no se les puede requerir que busquen errores. Muchas aplicaciones transitan por su vida dando por sentado que cada acceso al disco se ejecuta perfecta y rápidamente. Un volumen de disco que se llena a menudo hace que las aplicaciones se comporten de forma rara. Por ejemplo, una aplicación puede consumir toda la CPU disponible mientras intenta hacer una operación una y otra vez, sin darse cuenta de que no va a funcionar. Puede utilizare el comando strace para determinar qué es lo que está haciendo la aplicación (si está utilizando llamadas del sistemas).

Otras veces, las aplicaciones simplemente dejan de funcionar. Si no puede acceder a su base de datos, una aplicación web puede devolver páginas en blanco .

Conectándose y verificando el disco disponible (con du) es la forma más rápida de ver si el espacio en disco es el culpable.

Bloqueado en I/O

Cuando un proceso solicita alguna forma de I/O, el núcleo pone el proceso a dormir hasta que regresa la solicitud I/O. Si sucede algo con el disco (a veces como parte de una espiral swap, falla de disco o falla de red en sistemas de archivos de red), muchas aplicaciones son puestas a dormir al mismo tiempo.

Un proceso que es puesto a dormir puede ponerse en un sueño interrumpible o en un sueño ininterpretable. El primero puede eliminarse mediante una señal, pero el segundo no. Ejecutando ps aux se muestra el estado. El Listado 12 muestra que un proceso está en sueño ininterpretable y otro en sueño interrumpible.

Listado 12. Dos procesos en estado de sueño
apache   26575  0.2 19.6 132572 50104 ?        S    Feb13   3:43 /usr/sbin/httpd
root      8381 57.8  0.2   3844   532 pts/1    D    20:46   0:37 dd

El primer proceso del Listado 12, httpd, está en un estado de sueño interrumpible, indicado por la letra S a continuación del signo de interrogación. El segundo proceso, dd, está en un estado de sueño ininterpretable. Los sueños ininterpretables en general están asociados a accesos al disco duro, mientras que los sueños interrumpibles son por operaciones que emplean comparativamente más tiempo en ejecutarse, tales como las operaciones de NFS y socket.

Si uno encuentra un elevado promedio de carga (lo cual implica que hay muchos procesos en la lista de espera de ejecución) y muchos procesos en un estado de sueño ininterpretable, entonces puede existir un problema con el I/O del disco duro, ya sea porque el dispositivo está fallando o porque uno está intentando obtener demasiadas lecturas/escrituras de la unidad en forma simultánea.


Analizar la demanda

Esta sección abarca material para el tema 306.3 del examen 301 correspondiente al Nivel Senior del Linux Professional (LPIC-3). Este tema tiene un peso de 2.

En esta sección, aprenda a:

  • Identificar demandas de capacidad
  • Detallar las necesidades de capacidad de los programas
  • Determinar las necesidades de CPU/memoria de los programas
  • Ensamblar las necesidades de los programas en un análisis completo

Resolver los problemas inmediatos es una tarea clave para el admin del sistema. Otra tarea implica analizar cómo están funcionando los sistemas, con la esperanza de poder prever limitaciones de recursos y abordarlas antes de que se transformen en un problema. Esta sección trata sobre el análisis de la demanda actual, y la siguiente sección trata sobre predecir el uso futuro.

Pueden usarse dos enfoques para analizar la demanda actual: medir la demanda actual durante un cierto lapso (como una línea de base), o modelar el sistema para obtener un conjunto de parámetros de forma tal que el modelo refleje el comportamiento actual. El primer enfoque es más fácil y razonablemente bueno. El segundo es más preciso pero requiere mucho trabajo. La verdadera ventaja de crear un modelo se advierte cuando se necesita predecir el comportamiento futuro. Cuando se tiene un modelo del sistema, uno puede cambiar ciertos parámetros para hacerlos coincidir con las proyecciones de crecimiento y ver cómo cambiará el rendimientoe.

En la práctica, ambos enfoques se usan juntos. En algunos casos, resulta demasiado difícil modelar un sistema en particular, de manera que las mediciones son la única base sobre la cual basar las proyecciones de demanda y crecimiento. Sin embargo, las mediciones son necesarias para generar modelos.

Modelar el comportamiento del sistema

La actividad de una computadora puede ser modelada como una serie de listas de espera. Una lista de espera es una construcción donde las solicitudes van a un extremo y allí son retenidas hasta que un determinado recurso esté disponible. Una vez que el recurso está disponible, la tarea se ejecuta y sale de la lista de espera.

Pueden juntarse varias listas de espera para formar un sistema más grande. Puede modelarse un disco como una lista de espera en la que las solicitudes entran a un buffer. Cuando la solicitud está lista a ser etendida, es pasada a un disco. Esta solicitud generalmente proviene de la CPU, que es un recurso único con múltiples tareas compitiendo por el uso de la CPU. El estudio de las listas de espera y sus aplicaciones se llama teoría de las listas de espera.

El libro Analyzing Computer System Performance with Perl::PDQ ver enlace en Recursos) brinda una introducción sobre la teoría de las listas de espera y muestra cómo modelar un sistema de computación como una serie de listas de espera. También describe una biblioteca C llamada PDQ y una interfaz Perl asociada que permite definir y resolver las listas de espera para brindar estimadores de rendimiento. Así, puede estimarse el resultado de los cambios en el sistema mediante el cambio de parámetros.

Introducción a las listas de espera

La Figura 4 muestra una lista de espera única. Una solicitud llega desde la izquierda y entra en la lista de espera. A medida que las solicitudes son procesadas por el círculo, abandonan la lista de espera. Los bloques a la izquierda del círculo representan los objetos dispuestos en la lista de espera.

Figura 4. Lista de espera única
Lista de espera única

El comportamiento de la lista de espera se mide en términos de tiempos, tasas y tamaños. La tasa de arribo se indica con Lambda (Λ) y generalmente se expresa en ítems por segundo. Se puede determinar Λ observando el sistema durante un lapso razonable y contando los arribos. Un lapso razonable se define como al menos 100 veces el tiempo de servicio, que es el tiempo que dura el procesamiento de la solicitud. El tiempo de residencia es el tiempo total que una solicitud permanece en la lista de espera, incluido el tiempo empleado en su procesamiento.

La tasa de arribo describe la velocidad a la que los ítems se incorporan a la lista de espera, y el rendimiento define la velocidad a la que los ítems la abandonan. En un sistema más complejo, el rendimiento nodal define el rendimiento de un único nodo generador de listas de espera, y el rendimiento del sistema se refiere al sistema como un todo.

El tamaño del buffer no interesa la mayoría de las veces, ya que será finito y predecible siempre y cuando se cumplan las siguientes condiciones:

  • El buffer es suficientemente grande como para manejar los objetos de la lista de espera.
  • La lista de espera no crece en forma ilimitada.

La segunda restricción es la más importante. Si una lista de espera puede despachar solicitudes a una tasa de una por segundo pero las solicitudes entran a una velocidad mayor, entonces la lista de espera crecerá sin límites. En realidad, la tasa de arribo fluctuará, pero el análisis del rendimiento está relacionado con el estado estacionario, así que se emplean promedios. Quizás en un momento dado entran 10 solicitudes por segundo, y en otros momentos no entra ninguna. Si el promedio es menor que una por segundo, entonces la lista de espera tendrá una longitud finita. Si la tasa de arribo promedio es superior a la tasa a la que se despachan las solicitudes, entonces la longitud de la lista de espera continuará creciendo y nunca alcanzará un estado estacionario.

La lista de espera de la Figura 4 se llama lista de espera abierta porque la cantidad de solicitudes que arriban es ilimitada, y éstas no necesariamente regresan luego de ser procesadas. Una lista de espera cerrada retroalimenta el ingreso; hay un número finito de solicitudes en el sistema. Una vez que las solicitudes han sido procesadas, éstas regresan a la lista de espera de arribo.

El ejemplo clásico de una lista de espera es un mercado. La cantidad de personas que se incorporan a una cola, dividida por el periodo de medición, es la tasa de arribo. La cantidad de personas que son atendidas por el cajero, dividida por el periodo de medición, es el rendimiento. El tiempo promedio que emplea el cajero para procesar a un cliente es el tiempo de servicio. El tiempo promedio que un cliente espera en la cola, más el tiempo de servicio, es el tiempo de residencia.

Para entrar al dominio PDQ, considérese el siguiente escenario. Un servicio web ve 30.000 solicitudes en el curso de una hora. A través del rastreo de un sistema no cargado, se averigua que el tiempo de servicio es 0,08 segundos. La Figura 5 muestra esto dibujado como una lista de espera.

Figura 5. El servicio web modelado como una lista de espera
El servicio web modelado como una lista de espera

¿Qué información puede proporcionar PDQ? El Listado 13 muestra el programa PDQ requerido y su resultado.

Listado 13. Un programa PDQ y su resultado
#!/usr/bin/perl
use strict;
use pdq;
# Observations
my $arrivals = 30000; # requests
my $period = 3600; # seconds
my $serviceTime = 0.08; # seconds

# Derived
my $arrivalRate = $arrivals / $period; 
my $throughput = 1 / $serviceTime; 
# Sanity check -- make sure arrival rate < throughput
if ($arrivalRate > $throughput) {
        die "Arrival rate $arrivalRate > throughput $throughput";
}

# Create the PDQ model and define some units

pdq::Init("Web Service");
pdq::SetWUnit("Requests");
pdq::SetTUnit("Seconds");
# The queuing node
pdq::CreateNode("webservice", $pdq::CEN, $pdq::FCFS);

# The circuit
pdq::CreateOpen("system", $arrivalRate);

# Set the service demand

pdq::SetDemand("webservice", "system", $serviceTime);

# Run the report
pdq::Solve($pdq::CANON);
pdq::Report();

..... output ..
                ***************************************
                ****** Pretty Damn Quick REPORT *******
                ***************************************
                ***  of : Sat Feb 16 11:24:54 2008  ***
                ***  for: Web Service               ***
                ***  Ver: PDQ Analyzer v4.2 20070228***
                ***************************************
                ***************************************



                ***************************************
                ******    PDQ Model INPUTS      *******
                ***************************************


Node Sched Resource   Workload   Class     Demand
---- ----- --------   --------   -----     ------
CEN  FCFS  webservice system     TRANS     0.0800



Queueing Circuit Totals:

        Streams:      1
        Nodes:        1



WORKLOAD Parameters

Source        per Sec        Demand
------        -------        ------
system         8.3333        0.0800





                ***************************************
                ******   PDQ Model OUTPUTS      *******
                ***************************************


Solution Method: CANON

                ******   SYSTEM Performance     *******


Metric                     Value    Unit
------                     -----    ----
Workload: "system"
Mean Throughput           8.3333    Requests/Seconds
Response Time             0.2400    Seconds

Bounds Analysis:
Max Demand               12.5000    Requests/Seconds
Max Throughput           12.5000    Requests/Seconds


                ******   RESOURCE Performance   *******


Metric          Resource     Work              Value   Unit
------          --------     ----              -----   ----
Throughput      webservice   system           8.3333   Requests/Seconds
Utilization     webservice   system          66.6667   Percent
Queue Length    webservice   system           2.0000   Requests
Residence Time  webservice   system           0.2400   Seconds

El Listado 13 comienza con la línea "shebang" de UNIX que define el intérprete para el resto del programa. Las dos primeras líneas de código Perl solicitan el uso del módulo PDQ y el módulo strict. PDQ ofrece las funciones PDQ, mientras que strict es un módulo que impone un buen comportamiento de programación en Perl.

La siguiente sección del Listado 13 define variables asociadas a las observaciones del sistema. Dada esta información, la sección que le sigue a las observaciones calcula la tasa de arribo y el rendimiento. Este último es la inversa del tiempo de servicio—si se atiende una solicitud en N segundos, entonces pueden atenderse 1/N solicitudes por segundo.

Instalando PDQ

El tarball PDQ puede descargarse del sitio web del autor (ver Recursos). Desempáquelo en un directorio temporario con tar -xzf pdq.tar.gz, y cambie al directorio recién creado con cd pdq42. Luego, ejecute make para compilar el código C y el módulo Perl. Por último, cd perl5 y luego ejecute ./setup.sh para terminar de construir el módulo Perl e instalarlo en el directorio de su sistema.

El examen de sanidad verifica que la longitud de la lista de espera es limitada. Si bien la mayoría de las funciones PDQ notifican un error, el autor del módulo recomienda un control explícito. Si las solicitudes por segundo que entran son más que las que salen, entonces el programa muere con un error.

El resto del programa invoca las funciones PDQ en forma directa. Primero, el módulo es inicializado con el título del modelo. Luego, la unidad de tiempo y las unidades de trabajo se ajustan de modo que los reportes muestren información en la forma que se espera.

Cada lista de espera es creada con la función CreateNode. En el Listado 13, se crea una lista de espera llamada webservice (los nombres son etiquetas para ayudar a comprender el reporte final) que es del tipo CEN (un centro de creación de listas de espera, en oposición a un nodo de demora, que no hace ningún trabajo). La lista de espera es una típica FIFO ("first in, first out": primera adentro, primera afuera) que PDQ denomina una lista de espera primera en llegar-primera en ser atendida.

A continuación, se invoca CreateOpen para definir el circuito (un conjunto de listas de espera). La tasa de arribo al circuito ya ha sido calculada. Por último, la demanda por la lista de espera se establece con SetDemand. SetDemand define el tiempo empleado para completar una determinada carga de trabajo (una lista de espera dentro de un circuito).

El circuito finalmente se resuelve con la función Solve y se reporta con la función Report. Nótese que PDQ toma el modelo, lo convierte en una serie de ecuaciones, y luego las resuelve. PDQ no simula el modelo de ninguna manera.

Interpretar el resultado es sencillo. El reporte comienza primero con un encabezado y un resumen del modelo. La sección WORKLOAD Parameters proporciona más información de interés. El tiempo de servicio del circuito es 0,08 segundos, el cual fue definido. La tasa por segundo es la tasa de entrada.

La sección SYSTEM performance calcula el rendimiento del sistema como un todo. El circuito se las arregló para mantener una tasa de entrada de 8,3333 solicitudes por segundo. El tiempo de respuesta, que incluye los 0,08 segundos de tiempo de servicio, y el tiempo empleado en lista de espera fue de 0,24 segundos (esto se verá más adelante). El máximo rendimiento del circuito fue estimado en 12,5 solicitudes por segundo.

Si se observa con detenimiento la lista de espera, puede verse que es usada en un 66,6667%. La longitud promedio de la lista de espera es de dos solicitudes. Esto quiere decir que una solicitud entrante puede esperar tener dos solicitudes por delante en la lista de espera, más la solicitud que está siendo ejecutada. A los 0,08 segundos por solicitud, la espera promedio es 0,24 segundos, tal como se informó más arriba.

Este modelo podría ampliarse para mostrar los componentes del servicio web. En lugar de una única lista de espera representando el servicio web, podría tenerse una lista de espera para procesar la solicitud, una lista de espera para acceder a la base de datos, y una lista de espera para empaquetar la respuesta. El rendimiento del sistema debería permanecer igual si el modelo es válido, pero se tendría una comprensión de los procesos internos del servicio web. A partir de allí, se puede ejecutar "what if" y modelar una base de datos más veloz o más servidores web para ver qué tipo de mejora se obtiene como respuesta. Los números de recursos individuales nos dirán si una lista de espera en particular es el cuello de botella, y cuánto lugar hay para crecer.

El Listado 13 es un ejemplo básico de utilización de bibliotecas PDQ. Léase Analyzing Computer System Performance with Perl::PDQ (ver enlace en Recursos para aprender a construir modelos más complejos.


Predecir futuras necesidades de recursos

Esta sección abarca material para el tema 306.4 del examen 301 correspondiente al Nivel Senior del Linux Professional (LPIC-3). Este tema tiene un peso de 1.

En esta sección, aprenda a:

  • Predecir el punto de ruptura de capacidad de una configuración
  • Observar la tasa de crecimiento del uso de la capacidad
  • Graficar la tendencia del uso de la capacidad

La sección previa presentó la biblioteca PDQ y un ejemplo de reporte. El reporte mostró los valores calculados para la utilización y la carga máxima de una lista de espera y del sistema como un todo. Puede usarse el mismo método para predecir el punto de ruptura de una configuración. También pueden usarse gráficos para mostrar el crecimiento de un sistema a lo largo del tiempo y predecir cuándo va a alcanzar su capacidad.

Más sobre PDQ

El Listado 14 muestra el mismo servicio web que el Listado 13, pero dividido en dos listas de espera: una representando el tiempo de CPU en el servidor web para procesar la solicitud y la respuesta, y una que muestra el tiempo de espera hasta el retorno de la solicitud de la base de datos.

Listado 14. Un nuevo programa PDQ para el ejemplo de servicio web
#!/usr/bin/perl
use strict;
use pdq;
# Observations
my $arrivals = 30000; # requests
my $period = 3600; # seconds

# Derived
my $arrivalRate = $arrivals / $period;

# Create the PDQ model and define some units

pdq::Init("Web Service");
pdq::SetWUnit("Requests");
pdq::SetTUnit("Seconds");

# The queuing nodes
pdq::CreateNode("dblookup", $pdq::CEN, $pdq::FCFS);
pdq::CreateNode("process", $pdq::CEN, $pdq::FCFS);

# The circuit
pdq::CreateOpen("system", $arrivalRate);

# Set the service demand

pdq::SetDemand("dblookup", "system", 0.05);
pdq::SetDemand("process",  "system", 0.03);

# Solve
pdq::Solve($pdq::CANON);
pdq::Report();

The code in Listing 14 adds another queue to the system. The total service time is still 0.08 seconds, comprising 0.05 seconds for a database lookup and 0.03 seconds for CPU processing. Listing 15 shows the generated report.

Listing 15. The PDQ report from Listing 14
                ***************************************
                ****** Pretty Damn Quick REPORT *******
                ***************************************
                ***  of : Sun Feb 17 11:35:35 2008  ***
                ***  for: Web Service               ***
                ***  Ver: PDQ Analyzer v4.2 20070228***
                ***************************************
                ***************************************



                ***************************************
                ******    PDQ Model INPUTS      *******
                ***************************************


Node Sched Resource   Workload   Class     Demand
---- ----- --------   --------   -----     ------
CEN  FCFS  dblookup   system     TRANS     0.0500
CEN  FCFS  process    system     TRANS     0.0300



Queueing Circuit Totals:

        Streams:      1
        Nodes:        2



WORKLOAD Parameters

Source        per Sec        Demand
------        -------        ------
system         8.3333        0.0800





                ***************************************
                ******   PDQ Model OUTPUTS      *******
                ***************************************


Solution Method: CANON

                ******   SYSTEM Performance     *******


Metric                     Value    Unit
------                     -----    ----
Workload: "system"
Mean Throughput           8.3333    Requests/Seconds
Response Time             0.1257    Seconds

Bounds Analysis:
Max Demand               20.0000    Requests/Seconds
Max Throughput           20.0000    Requests/Seconds


                ******   RESOURCE Performance   *******


Metric          Resource     Work              Value   Unit
------          --------     ----              -----   ----
Throughput      dblookup     system           8.3333   Requests/Seconds
Utilization     dblookup     system          41.6667   Percent
Queue Length    dblookup     system           0.7143   Requests
Residence Time  dblookup     system           0.0857   Seconds

Throughput      process      system           8.3333   Requests/Seconds
Utilization     process      system          25.0000   Percent
Queue Length    process      system           0.3333   Requests
Residence Time  process      system           0.0400   Seconds

Obsérvese el resultado en el reporte, y nótese que el tiempo de respuesta promedio ha disminuido respecto del Listado 13 y el máximo de solicitudes por segundo ha aumentado de 12,5 a 20. Esto es así porque el nuevo modelo permite procesos por tuberías. Mientras una solicitud está siendo despachada a la base de datos, otra solicitud puede ser procesada por la CPU. En el modelo anterior, esto no era posible calcularlo porque sólo se usaba una lista de espera.

Aún más importante, puede advertirse que la base de datos está utilizada en un 42% y la CPU es utilizada sólo en un 25%. Por lo tanto la base de datos será la primera en alcanzar su capacidad cuando el sistema reciba una carga mayor.

Si se cambian los arribos para que sean 60.000 por hora, se verá que el tiempo promedio de respuesta aumenta a 0,36 segundos, y que la base de datos alcanza el 83% de utilización. También se verá que de los 0,36 segundos, 0,30 se los emplea esperando a la base de datos. Por lo tanto, el tiempo sería mejor empleado, haciendo más rápido el acceso a la base de datos.

La capacidad máxima puede definirse de diferentes maneras. A 20 solicitudes por segundo (en la parte superior del reporte), el sistema está al 100% de su capacidad. También puede optarse por definir la capacidad como el tiempo promedio de respuesta. A aproximadamente 15 solicitudes por segundo, el tiempo de respuesta será mayor que un cuarto de segundo. Si el objetivo es mantener la respuesta por debajo de 0,25 segundos, el sistema alcanzará su capacidad en ese punto, si bien aún hay lugar para crecer en el hardware.

Usar gáficos para el análisis

Los gráficos son una excelente forma de representar la información histórica. El gráfico puede seguirse durante un periodo prolongado, por ejemplo entre 6 meses y un año, y obtenerse de ellos una idea sobre la tasa de crecimiento. La Figura 6 representa el uso que hace de la CPU un servidor de aplicaciones en el curso de un año. Las mediciones promedio de uso diario se volcaron a una planilla de datos y se graficaron. También se agregó una línea de tendencia para mostrar el crecimiento.

Figura 6. Graficando el uso de la CPU de un servidor
Graficando el uso de la CPU de un servidor

A partir de este gráfico puede proyectarse el uso futuro (asumiendo que el crecimiento permanece constante). El crecimiento en el servidor de acuerdo a la Figura 6 es aproximadamente 10% cada 3 meses. Los efectos de las listas de espera son más pronunciados cuando la utilización es mayor, de manera que podría ser necesario mejorar y ampliar el sistema antes de que se alcance el 100% de uso.

Cómo graficar

El método de la planilla no puede ampliarse apropiadamente cuando se usan muchos servidores con muchas mediciones diferentes. Existe un método que toma los resultados de sar y los pasa por una herramienta de generación de gráficos como GNUplot. También pueden considerarse las herramientas gráficas disponibles, muchas de las cuales son de fuente abierta. La categoría de fuente abierta incluye una serie de herramientas basadas en el paquete RRDTool.

RRDTool es una serie de programas y bibliotecas que colocan los datos en una base de datos circular (RRD). La RRD archiva datos en forma continua a medida que van llegando, de manera que pueden tenerse datos horarios para el último año y promedios de 5 minutos para la semana. Esto brinda una base de datos que nunca crece y que constantemente recorta los datos más antiguos. RRDTool también viene con herramientas para hacer gráficos.

Ver en la sección Recursos diferentes buenas herramientas de generación de gráficos.

Qué graficar

Debería graficarse cualquier información de importancia para su servicio, y cualquier cosa que potencialmente pudiera usarse para tomar decisiones. Los gráficos también juegan un rol secundario al ayudar a averiguar lo que sucedió en el pasado, de manera que pueden graficarse ítems tales como velocidades de ventiladores. Normalmente, sin embargo, se centra la atención en graficar las estadísticas de la CPU, la memoria, el disco y la red. De ser posible, conviene graficar los tiempos de respuesta de los servicios. Esto no sólo ayudará a tomar mejores decisiones basadas en lo que esperarán los usuarios, sino que la información también le ayudará en caso de tener que desarrollar modelos de su sistema.


Resumen

En este instructivo vimos cómo medir y analizar el rendimiento. También vimos cómo usar estas mediciones para resolver problemas.

Linux brinda una gran cantidad de información sobre la salud del sistema. Ciertas herramientas, tales como vmstat, iostat y ps proporcionan información en tiempo real. Otras herramientas, tales como sar, proporcionan información de periodos más prolongados. Recuerde que cuando se usan vmstat y iostat, el primer valor reportado no es en tiempo real!

Al resolver los problemas de un sistema, primero debe intentarse identificar los síntomas del problema, tanto para comprenderlo como para saber cuando ha sido solucionado. Por lo tanto, mida los recursos del sistema mientras el problema está presente (si es posible) a fin de determinar su origen. Una vez que se ha identificado la solución, impleméntela y evalúe los resultados.

El módulo Perl PDQ permite resolver problemas en las listas de espera. Luego de reemplazar su sistema con una serie de lista de espera, usted puede escribir un script Perl utilizando las funciones PDQ. Después puede usar este modelo para calcular la demanda en base al uso actual y al uso futuro predicho.

Tanto los modelos como los gráficos pueden usarse para predecir el crecimiento. Idealmente, deben usarse ambos métodos y comparar los resultados.

Aquí termina la serie sobre la preparación para el examen LPIC 3. Si usted va a presentarse al examen, le deseo éxito y espero que esta serie le resulte de utilidad.

Recursos

Aprender

Obtener los productos y tecnologías

  • Obtenga la fuente para PDQ, además de las instrucciones para instalarlo en distintos sistemas operativos.
  • RRDTool, la base de la mayoría de los sistemas de monitoreo de redes de fuente abierta, es un derivado del famoso paquete de software Multi Router Traffic Grapher. RRDTool puede usarse como parte de otro paquete o en los scripts propios del usuario.
  • Cacti es uno de los mejores paquetes de monitoreo de fuente abierta disponibles. Está hecho principalmente para dispositivos de red pero ha sido extendido para realizar una variedad de tareas vinculadas a sistemas. Cacti cuenta con una activa comunidad de usuarios siempre deseosos de colaborar en los foros.
  • ZABBIX es otro paquete de monitoreo de sistemas de fuente abierta que vale la pena considerar.
  • Vea el área Tivoli de developerWorks para mayor información sobre los sistemas empresariales, de redes, de seguridad y las herramientas de gestión de aplicaciones de IBM. En particular, la solución Tivoli Composite Application Management le ayuda a aumentar el rendimiento y la disponibilidad de las actuales aplicaciones compuestas que son críticas para los negocios, incluyendo las tecnologías de portales y aquellas basadas en SOA.
  • Con el software de prueba de IBM, disponible para descargar directamente de developerWorks, construya su próximo proyecto de desarrollo con Linux.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=651092
ArticleTitle=Preparación para el examen 301 del LPI, Tema 306: Planificación de capacidad
publish-date=07152011