DISEÑO Y EVALUACIÓN DE CONFIGURACIONES
Práctica 4: DOMINGO LÓPEZ OLLER
Uso de programas de monitorización de un sistema
Lista de correo
Me he suscrito a la lista de correo con el correo [email protected].
Me he dado de alta en el sistema de envío de prácticas, y tengo el nick domingolopezoller y el id 51
OBJETIVO DE LA PRÁCTICA
El objetivo de la práctica es la medición de los siguientes valores en un ordenador cuando se inicia normalmente y cuando está en una carga alta.
MEDIDAS A CONSIDERAR:
- Utilización de procesador
- Monitorización del tráfico en la tarjeta de red
- Tráfico en disco duro
Estas mediciones se van a hacer sobre la siguiente máquina bajo el sistema operativo Windows XP Professional:
Esta información se ha generado con Everest 5.001650 y se corresponde con uno de los 2 núcleos,el resumen completo de todo el sistema
está en el siguiente enlace. Pinche aquí
MONITOR ESCOGIDO
Yo he escogido el SYSTEM EXPLORER, visto en la práctica 2, para generar las gráficas que se presentarán aunque puede hacerse en otros
como el propio Everest.
La forma de proceder es la siguiente:
Ya en la última ventana escogeremos qué queremos medir y qué señales queremos incorporar a la gráfica para ver su evolución.
También utilizaré el Systemometer para desarrollar un fichero log de lo que ha ocurrido en cada prueba similar al que se puede generar con Everest y
al mismo tiempo mostrar el desarrollo de la prueba en alta carga y la media en ese momento.
El manejo de Systemometer es idéntico al System Explorer con las mismas opciones.
Inicialmente el sistema tiene los siguientes procesos: Apache 2.0, Explorer, Ext2Mgr, GoogleDesktop, NOD32, drivers de periféricos como cámara web entre otros.
Nota: Las variables que voy a utilizar para realizar las mediciones serán lo más vistosas posibles a fin de que se vean cambios para poder explicar bien lo que ocurre aunque
pueden considerarse otras medidas.
ANÁLISIS PROCESADOR
El objetivo es mostrar el comportamiento del procesador en baja y alta carga. En concreto se analizarán los siguientes puntos:
- % de tiempo de procesador: Esta variable me va a permitir ver la carga que suponen los proceso en la ejecución en el kernel del sistema operativo. Aquí se cuentan tanto procesos que se inician al arrancar el sistema como aquellos cuando se hacen cambios de contexto
- % de tiempo de usuario: Esta variable me va a permitir ver la carga que suponen los procesos que carga el usuario respecto a los que carga el sistema nada más arrancar
- % de tiempo de interrupción: Es el tiempo que el procesador invierte recibiendo y atendiendo interrupciones de hardware durante los intervalos de ejemplo. Este valor es un indicador indirecto de la actividad de los dispositivos que generan interrupciones, como el reloj del sistema y periféricos del sistema.
- % de tiempo inactivo: Es el valor complementario al tiempo de procesador, se evalúa el tiempo que el procesador no se está utilizando
El hecho de escoger estas medidas es ver el comportamiento del procesador a nivel de uso con los procesos 'superusuario', los de usuario y lo que suponen las interrupciones del sistema en este hecho.
BAJA CARGA
Para el sistema inicial se puede obtener el siguiente resultado:
A la vista de los resultados podmos ver que el sistema no tiene una gran carga de procesos, sólo 60, lo que parece que no supone
una gran carga al procesador y de ahí que el tiempo inactivo sea casi del 100%. Sin embargo sí podemos apreciar los picos debidos a los cambios de contexto que se hacen entre procesos, lo cual es lógico
dado que esos 60 procesos tienen que utilizar el procesador y habrá acciones que se realicen y que requieran procesador.
También se puede ver que los procesos activos por el usuario están por debajo de los que crea el sistema en cuanto a carga, también es lógico porque la mayoría de los programas que
ejecutamos a nivel de usuario van a poder ejecutarse como 'superusuario' cuando necesiten acceder a hardware y cambie su permisos.
Por lo tanto, el tiempo de procesador tendrá los procesos del sistema más los de usuario cuando estos pasen a superusuario.
En cuanto a las interrupciones, no podemos decir que no ocurran, pero la cantidad es tan pequeña en porcentaje que no se aprecia en esta gráfica. Esto viene a decir que las interrupciones no van a suponer una carga en el
procesador ya que en los picos no se aprecia ningún cambio. El procesador se utiliza a raiz de la acción a ejecutar, los cambios de contexto
que se originan con la interrupción no suponen una carga excesiva alta. Este hecho se verá en carga alta donde debe tener un comportamiento similar.
ALTA CARGA
Para poder poner el sistema en alta carga con el procesador podemos optar por:
- Iniciar muchos procesos que obligue a hacer muchos cambios de contexto (lo que viene siendo arrancar muchos programas de bastante carga como juegos)
- Iniciar un Benchmark sobre el procesador
La opción que he escogido por rápida es la segunda, la primera va a permitir ver una comportamiento progresivo a medida que se hacen los cambios
pero como me interesa ver el comportamiento de las variables en baja y alta carga el benchmark me permite hacerlo de forma rápida.
El benchmark que voy a utilizar se llama Ciusbet Hardware Benchmark 1.8 y se puede descargar en el siguiente enlace: http://ciusbet-hardware-benchmark.uptodown.com/
Una vez he iniciado el benchmark se obtiene el siguiente resultado:
Si realizamos este análisis en el SystemMometer podremos obtener el siguiente resultado:
En esta imagen es posible ver el comportamiento instantáneo como el System Explorer y a la vez la media alcanzada en color verde viendo así el comportamiento del sistema.
Con este programa se puede obtener un fichero log que indica la evolución del sistema en esta prueba: Pulse aquí
En este fichero log se puede ver también que la evolución de las 2 CPU no es simétrica, se puede ver que aunque hay dos núcleos la carga en ellos no es la misma, siempre está trabajando uno más que otro.
Trabajará uno un poco más, el que realice más cambios de contexto por los procesos que tiene (en concreto la CPU-1 tiene el antivirus como uno de sus procesos y esto supone una carga adicional), pero sí se puede ver que conforme aumenta la carga del procesador esto se va equilibrando para tener un meyor rendimiento.
A la vista de los resultados, se puede ver que hay un gran cambio entre las dos gráficas presentadas, en la segunda puede verse que en alta carga el procesador provoca que el tiempo de procesador aumente mucho y el tiempo inactivo
baje como era de esperar al exigirle más rendimiento. Otra cosa que se puede ver es lo dicho del proceso usuario que pasa a superusuario, cuando alcanza el 90%, el usuario ha arrancado los procesos del benchmark y provocan una gran carga
pero al iniciar los cálculos intensivos en él se pide más carga al procesador y la carga de usuario cae por el cambio a superusuario.
En este caso sí podemos observar el efecto de las interrupciones por la cantidad que se generan al finalizar el proceso de gran carga en el procesador.
También he querido comprobar al acabar el benchmark el proceso de carga de un programa como nero y el resultado es el pico que se puede ver al final. Este pico dependerá del tipo de programa y los recursos que necesite para iniciarse
He podido comprobar que el procesador trabaja normalmente en un 5%, salvo que esté ejecutando algún programa que le exija mucha carga como el benchmark o prácticas de asignaturas como ALG o TA.
He comprobado en Everest que la temperatura suele rondar los 65º que es un valor aceptable considerando un portátil, por lo tanto, el comportamiento del procesador es correcto.
ANÁLISIS RED
El objetivo es mostrar el comportamiento de la red en baja y alta carga. En concreto se analizarán los siguientes puntos:
- Segmentos enviados por segundo: Se analiza el número de segmentos que se envían a la red
- Segmentos recibidos por segundo: Se analiza los segmentos que se reciben de la red, tantos lo buenos como los erróneos
- Datagramas por segundo: Se analiza el número de paqutes UDP que se envían o reciben en la red
El hecho de escoger estas medidas es porque quiero ver el volumen de tráfico que se genera en la red cuando estoy trabajando por la web e identificar el tipo de paquete que se procesa
o lo que es lo mismo, si todo el tráfico es TCP o UDP y por qué. En este caso presupongo que la carga será mayor de TCP por lo que me interesa ver también el comportamiento de descarga y de subida.
Quizá fuera interesante incluir los paquetes perdidos pero la cantidad de paquetes que se pierden es muy pequeña y no se distingue con los paquetes UDP que
sí quería probar.
BAJA CARGA
Para el sistema inicial se puede tener el siguiente resultado:
Se puede ver que salvo que algún servicio activo necesite una conexión puntual para ver nueva versión, como hace el antivirus, y el propio sistema
que está evaluando la conexión por WIFI con el router, por lo general si vemos un comportamiento plano. Esto es lógico porque el tráfico depende de
las peticiones que realicemos, si no solicitamos nada a un servidor, no podemos estar obteniendo paquetes.
ALTA CARGA
Para poder poner el sistema en alta carga basta con iniciar unas cuantas páginas web que incluyan formato texto, animaciones flash, videos, música, imágenes,...
tales como flickr, tuenti, marca, youtube, etsiit, google o swad entre otras.
El resultado que se obtuvo es el siguiente:
Si realizamos este análisis en el SystemMometer podremos obtener el siguiente resultado:
En esta imagen es posible ver el comportamiento instantáneo como el System Explorer y a la vez la media alcanzada en color verde viendo así el comportamiento del sistema.
Con este programa se puede obtener un fichero log que indica la evolución del sistema en esta prueba: Pulse aquí
A la vista de los resultados, se puede ver que conforme iba abriendo ventanas en firefox y cargando páginas se han ido haciendo los picos de peticiones que son de tipo TCP y muy poco o nada UDP.
Así, este volumen de peticiones ha producido los picos que vemos en la gráfica hasta el punto de estabilizarse cuando todas las páginas se han cargado y cada x tiempo solicitan actualización al servidor.
En cuanto a lo que comenté sobre el índice de descarga y envío, puede verse que al iniciar una petición a una página el número de segmentos enviados es mayor que el recibido y ya conforme iba llamando más páginas este valor
iba creciendo sin embargo no siempre está por encima. A medida que el servidor devuelve paquetes, una gran cantidad dependiendo de la información que contenga la página, se vé que la descarga aumenta mucho y se queda
por encima de la tasa de envío. En este caso estamos realizando peticiones de html, si colocásemos el emule o el ares veríamos que la descarga sería mucho mayor, este es el motivo de que la tasa de descarga y de envío que tenemos
contratado no sea igual y sea mayor la descarga que la subida, siempre descargaremos más información que la que solicitamos. Ej: Solicitamos información de www.marca.com con uno o varios paquetes enviados pero la respuesta que
contiene multimedia, animación, texto,... lleva mucha más información y recibo más paquetes que los enviados.
Se ha podido comprobar por tanto que el tráfico de la red html confirma que el índice de descarga es mayor que el de subida y se aprecia que el 99% del tráfico por internet se corresponde con paquetes TCP, lo cual es lógico ya que
son más rápidos que los UDP y ligado a html desde hace tiempo mientras que el UDP se utiliza en aplicaciones más específicas y no tanto en el protocolo http.
ANÁLISIS DISCO DURO
El objetivo es mostrar el comportamiento del disco en baja y alta carga. En concreto se analizarán los siguientes puntos:
- % Tiempo de disco: Tiempo de las operaciones que se realizan de disco
- % Tiempo de escritura de disco: Tiempo ocupado en realizar escritura en disco
- % Tiempo de lectura de disco : Tiempo ocupado en realizar lectura en disco
- Lectura en disco por segundo: Analiza las operaciones de lectura por segundo en el disco duro
- Escritura en disco por segundo: Analiza las operaciones de escritura por segundo en el disco duro
El objetivo de esta prueba es ver el comportamiento del disco duro cuando se realizan operaciones de lectura y escritura cuando realizamos alguna de estas acciones:
- Copiar una carpeta de un sitio a otro
- Reproducir un video
- Reproducir un sonido
- Abrir un fichero doc y escribir y guardar
Estas operaciones se realizarán para poner el sistema en alta carga.
BAJA CARGA
Para el sistema inicial se puede obtener el siguiente resultado:
Se puede ver que el disco al principio no tiene carga dado que la memoria de 2GB de RAM permite cargar lo necesario al principio y no requiere de demasiado tráfico de disco.
Los picos que se aprecian son las escrituras que se hacen en disco del contenido que hay almacenado en caché y que al modificarse se copia en el bloque alojado en disco duro pero sin quitarlo y obtener uno nuevo.
Por lo demás se aprecia claramente el comportamiento plano de inactividad en el disco
ALTA CARGA
Tras realizar las operaciones antes mencionadas se puede obtener el siguiente resultado:
Si realizamos este análisis en el SystemMometer podremos obtener el siguiente resultado:
En esta imagen es posible ver el comportamiento instantáneo como el System Explorer y a la vez la media alcanzada en color verde viendo así el comportamiento del sistema.
Con este programa se puede obtener un fichero log que indica la evolución del sistema en esta prueba: Pulse aquí
En la imagen se puede ver que cuando inicio las operaciones tengo que guardar lo que hay en caché para colocar los nuevos bloques que estoy solicitando en caché y de ahí que el tiempo de disco
y escritura se dispare tanto al principio.
Después, cuando inicié la reproducción de audio y video se ve la tasa de lectura en disco se dispara para coger los datos del disco y colocarlos en caché, lo que puede hacer que se tengan que
guardar algunos bloques y de ahí el pico grande de escritura, y podemos ver que como los bloques no son de MB se están solicitando bloques para ir reproducciendo y por eso no cae la tasa de lectura a 0
sino que baja cuando la caché tiene lo que necesita y aumenta cuando hay faltas.
Aunque suene una obviedad, las variables % están representando el mismo comportamiento que las variables medias cada segundo como son la lectura y escritura.
He querido colocar las variables % y las absolutas para ver que no es lo mismo ver un término promedio que el término real, con las medidas reales sí he podido explicar el comportamiento
del disco en alta carga mientras que si fuera con las de % no sería posible por los valores tan pequeños que se muestran.
Se puede comprobar que el disco duro responde a nuestras espectativas, si nos ponemos a reproducir un video vemos que el número de lecturas y escrituras aumenta aunque no podemos decir nada
sobre si lo hace más o menos rápido, eso ya depende de las características técnicas del disco.
CONCLUSIONES
A la vista de los resultados obtenidos en las pruebas anteriores he podido comprobar que el sistema responde bien en carga baja y alta.
En esta práctica se han evaluado el procesador, la red y el disco duro pero se podrían haber considerado otras posibilidades como:
Control de velocidad de los ventiladores en un sobremesa dependiendo de la carga del sistema
Control de temperatura del sistema en alta carga utilizando juegos como emuladores o los de última generación que evalúan la resistencia de la tarjeta gráfica
Control de la memoria RAM en la que podría verse qué procesos consumen más RAM, como es el caso de firefox si se deja tiempo.
Comportamiento de la tarjeta gráfica para ver su calidad según la memoria dedicada y la carga aplicada
...
Como vemos, podemos realizar muchísimos análisis sobre nuestro sistema sin embargo debemos estar muy seguros de lo que medimos y cómo lo medimos. No es lo mismo medir la temperatura del sistema en invierno que en verano,
ni tampoco medir la tarjeta gráfica con un simulador de vuelo que con un juego de los años 90.
Estas mediciones nos tienen que servir para ver si el sistema funciona correctamente o si el sistema comienza a fallar, ya que si por ejemplo la prueba del mes pasado daban temperaturas de 65º y ahora dieran de 75º y no
estamos por julio deberemos de encontrar las causas. Así mismo, en el caso de mis pruebas sobre procesador, si veo que uno de los procesadores está teniendo toda la carga y el otro no recibe carga podré ver que puede estar estropeado el núcleo.
En definitiva, el mantenimiento del equipo pasa por conocer las características técnicas del hardware, de su fiabilidad y de las pruebas que hagamos para comprobar su rendimiento y estabilidad.
DOMINGO LÓPEZ OLLER Ingeniero Técnico Informática Sistemas
Práctica 4 de Diseño y Evaluación de configuraciones.