Tema anterior: representación gráfica
Tema siguiente: benchmarking
Página principal de la asignatura
Página del profesor
Página principal del grupo GeNeura

3. Solución de problemas en un sistema informático

Una vez evaluado el rendimiento de un sistema informático, hay una serie de medidas que se pueden tomar para sintonizarlo, es decir, mejorar sus prestaciones en algún aspecto. En concreto, puede hacerse algo de lo siguiente:

El libro de referencia para este tema es Portada del libro System Performance TuningSystem Performance Tuning, 2nd Edition, de Gian Paolo Musumeci y Mike Loukides, de O'Reilly. Dedica un capítulo a cada uno de los subsistemas del ordenador, indicando cómo detectar problemas usando monitores, y cómo solucionarlos usando las diferentes técnicas al alcance del administrador del sistema. La edición es del año 2002, y está, por tanto, bastante actualizado. Sus sistemas operativos de referencia son Linux y Solaris. Microsoft y Windows ni siquiera aparecen en el índice. También puedes comprar el libro en Amazon UK.

Conviene también tener en cuenta una serie de principios a la hora de mejorar las prestaciones de un sistema:

  1. Conoce y comprende tu entorno: es conveniente saber todo lo que hace el sistema: qué subsistemas tiene activados, cuáles son los servicios que se arrancan y qué es lo que hacen, qué procesos tiene activos en cada momento. Conviene también tener ciertas nociones de cómo funciona el sistema operativo con el que se trabaja, la red, el subsistema de E/S. No es necesario bajar hasta el nivel de saber qué registros de la CPU se usan en cada momento, pero sí tener cierta idea de todo. Así, en el caso de que algo vaya mal, se podrá identificar rápidamente la causa, y evitarla.
  2. Hay que buscar el equilibrio: en inglés se suele decir TANSTAAFL; there is not such a thing as a free lunch, es decir, no existen los almuerzos gratuitos: lo que te dan gratis por un lado, te lo cobran por otro. Por ejemplo, no se puede mejorar la velocidad percibida por un usuario sin empeorar la de todos los demás usuarios; no se puede optimizar al máximo un programa sin aumentar, como mínimo, el tiempo que se le dedica al mismo. Y si quiere gastarse uno el dinero en aumentar la memoria, dinero sin el que se queda para añadir un disco duro más al sistema.
  3. Throughput contra latencia: el throughput se refiere a la cantidad de cosas que se pueden hacer, o transmitir, en la unidad de tiempo; por ejemplo, a la cantidad de MB/s que se pueden escribir en disco, o a la cantidad de procesos que un procesador es capaz de procesar (valga la redundancia) en la unidad de tiempo. La latencia, sin embargo, es el tiempo total que tarda en hacerse algo. Por ejemplo, en una red, la latencia sería el tiempo que tarda un paquete para transmitirse de un punto a otro de la red, mientras que el throughput sería la cantidad de bytes que la red es capaz de soportar. Para ver cómo un concepto se opone al otro, mirar este artículo sobre el tamaño de los paquetes en las redes: cuanto más pequeño es un paquete, menor es la latencia (tarda menos en llegar de un punto de la red a otra), pero disminuye el throughput, porque el tamaño relativo del overhead, es decir, de la información adicional que se le añade al paquete, toma mayor importancia.
  4. No sobreutilices un recurso: ningún recurso usado al 100% estará al óptimo de su capacidad, sino más bien por encima. Por encima del 50% ya empieza a acusar el uso; por encima del 70% ya empieza a estar sobrecargado. Todo esto, claro está, depende del sistema operativo: en Windows, un uso del 95% cuando hay un par de programas ejecutándose es de lo más normal; sin embargo, en cualquier sistema Unix, sería preocupante.
  5. Diseña las pruebas con cuidado: aplica el primer principio, y mira bien lo que vas a medir antes de medirlo. Por ejemplo, si para medir la velocidad de lectura/escritura de un CD copias parte de su contenido al disco duro, estarás midiendo tanto la velocidad del disco duro, como del interfaz IDE, como de la memoria, como de la CPU; algunas de esas cosas no se podrán evitar, pero sí, por ejemplo, el uso del disco duro; de la misma forma, si mides la velocidad de la red bajándote algo de una página web, tendrás que descontar el efecto del servidor web, del disco del servidor, la carga del servidor... trata de diseñar las pruebas de forma que eliminen todos los factores del sistema que no interesen, o que puedan afectarlo. Y esto se puede aplicar a cualquier medición o benchmark.
  1. Busca en Internet o en el manual de tu sistema operativo cómo puedes alterar los parámetros siguientes de tu sistema operativo: tamaño de la rodaja temporal, índice de supervivencia de página, número máximo de usuarios, número máximo de procesos.
  2. Mirando las pantallas de configuración de tu ordenador, dí qué parámetros del hardware se pueden cambiar: reloj del sistema, por ejemplo, o frecuencia del bus del sistema.
  3. Buscar en Internet algún contrato de prestación de servicios que incluya condiciones sobre las prestaciones de un sistema que va a contratar; presentar el enlace.

En general, un administrador o administradora de un sistema tiene que mantener a todos sus usuarios felices (aunque esto sea matemática y filosóficamente imposible), y para ello tiene que cuidar el sistema como si de un bebé se tratara; en general, también, como tal bebé, al principio da mucha guerra, pero luego es capaz de ir solo al cuarto de baño. Por tanto, tiene que plantear la gestión de un sistema de la siguiente forma:

Tanto los usuarios como el administrador pueden mejorar el funcionamiento del sistema. Por ejemplo, algunas medidas que pueden tomar los usuarios si buenamente les da la gana y les apetece (o si el BOFH no les deja otro remedio) es:

  1. Tomar varios programas de una misma categoría, tales como navegadores, programas de correo, editores; realizar en todos ellos la misma tarea, y evaluar el consumo de recursos de los mismos, especialmente memoria consumida y porcentaje de CPU. Indicar en un entorno donde los recursos no sean excesivos, cuál se usaría.

En cuanto al superusuario, hay muchas cosas que puede llevar a cabo para aligerar la carga del sistema:

Esta es una parte de las variables que aparecen en el directorio /proc/sys/kernel: -rw-r--r-- 1 root root 0 abr 1 14:26 real-root-dev -rw-r--r-- 1 root root 0 abr 1 14:26 rtsig-max -r--r--r-- 1 root root 0 abr 1 14:26 rtsig-nr -rw-r--r-- 1 root root 0 abr 1 14:26 sem

Como se ve, algunas son de solo lectura, y otras de lectura y escritura; las primeras solo muestran los valores de las variables, que habrá que alterar usando otro procedimiento (recomplidando el kernel, por ejemplo), mientras que otras son de lectura/escritura, y se pueden cambiar sobreescribiéndolas o con un simple editor de textos.

Este tipo de políticas son utilizables en el caso genérico, es decir, nunca están de más. En particular, para cada uno de los subsistemas, hay una serie de parámetros a los que habrá que controlar. Los veremos a continuación.

  1. Comparar dos programas que hagan la misma labor (por ejemplo, dos procesadores de textos), ejecutando simultáneamente un monitor, y calcular a ojo de buen cubero los recursos de CPU y memoria que consumen. ¿Si hay varias copias del programa, cómo evoluciona el consumo de recursos?
  2. Monitorizar la CPU y memoria de un ordenador recién encendido; eliminar servicios innecesarios del arranque, y volver a hacer la monitorización. ¿Ha mejorado algo?
  3. Modificar algún parámetro del sistema operativo, tal como la rodaja temporal; monitorizar el sistema antes y después de la modificación. ¿Se nota alguna diferencia?

Monitorización de CPU en Windows NT/2000/XP

En NT (y supongo que en sus sucesores Windows 2000 y XP, sucederá más o menos igual), aunque no tiene mucho remedio, se puede tratar de usar el monitor de prestaciones del sistema, PERFMON, para mirar el estado del sistema. Los parámetros que más afectan a la CPU son:

  • Procesador: %tiempo del procesador. Si es superior al 70%, lo cual sucede si estás ejecutando aunque sea solo un programa, la cosa está chunga. Como en mi (antiguo) Pentium 166 con 32 Megas de memoria pasaba (y eso que iba sobrao), pues no sé muy bien como se va a solucionar el tema. Pero para saber exactamente de donde viene el problema, hay que mirar los siguientes parámetros.
  • Procesador: interrupciones por segundo. Si es excesivamente alto, el tiempo de procesador puede estar causado por algún dispositivo o interfaz, como IDE, o dispositivos antiguos de red.
  • Sistema: Llamadas al sistema por segundo; cuando hay más interrupciones que llamadas al sistema, se confirma que los dispositivos están generando más demanda que las llamadas software a los servicios NT.
  • Cambios de contexto por segundo. Si es excesivamente alta, un tipo de procesador en el cual el cambio de contexto esté optimizado, como los RISC, puede mejorar prestaciones. Recordar que WinNT funciona en procesadores Alpha y MIPS, además de los Intel (aunque no estoy muy seguro de que el XP lo siga soportando); también se podría cambiar, simplemente, a un procesador de una generación posterior.

El concepto de una CPU sobrada varía con el tipo de ordenador. En un sistema que ejecute un servidor web o una base de datos, una CPU al 100% no podrá con ningún tipo de carga pico; sin embargo, en un sistema intensivo de cálculo bien administrado, se tratará de lograr que la carga esté siempre al 100%. Aunque no hay que tomar la carga como único indicativo de si un sistema está yendo bien (en particular, no se pueden comparar dos ordenadores diferentes con respecto a la carga), sí está claro que, en un momento determinado, un sistema puede tener la CPU sobrecargada.

La CPU no es el tipo de cosas con las que uno deba jugar, pero en todo caso algo se puede hacer para que vaya más rápido. Estas mejoras no llegarán por el lado del software (aunque hay utilidades que supuestamente mejoran las prestaciones de la CPU), sino por el lado del hardware: cambiar la velocidad en megahercios a la que funciona la CPU. En placas actuales, esto se puede hacer directamente desde el setup de la BIOS (Basic Input/Output System). La estrategia que hay que seguir es la siguiente (tal como se puede encontrar, por ejemplo, en http://www.firingsquad.com o en http://www.sharkyextreme.com).

Una estupenda guía para overclockers está en la guía básica de overclocking de CPUs de Sharky Extreme. Hay también bastantes ejemplos de overclocking en Overclockers UK, inclusive accesorios tales como ventiladores y carcasas. Hay varios artículos en castellano, como por ejemplo una guía bastante completa en castellano y un artículo relativamente reciente sobre conceptos y metodología en Hardware12V. Otros sitios, como Hard-H20, tratan específicamente de recursos y chismes diversos para refrigerar el procesador y otros componentes usando agua.

En el caso de que se trate de un sistema multiprocesador, se puede usar mpstat, que, aunque no se instala por defecto en Linux, se le puede encontrar dentro del paquete sysstat (disponible, por ejemplo, en Fedora). En el caso de Linux la información que se da no es tan completa como en el caso de Solaris: poco más o menos que te da la misma que vmstat, pero desglosada por procesador. Sin embargo, una de las cosas que interesan en los sistemas multiprocesador es la existencia de problemas con los mutexes; es decir, bloqueos entre procesadores. Muchos mutexes solicitados y no dados pueden causar problemas de bloqueo. Pero vamos, que si llegáis a preocuparos por los mutexes, es que el resto del sistema va fenomenal, o sea que tampoco es como para echarse a llorar.

  1. Contar una experiencia de overclocking propia o encontrada en algún sitio de Internet.

La actividad de la memoria consiste principalmente en swapping, o escritura de un proceso completo, con toda la memoria correspondiente, en disco, y paginación, en la cual se cargan o descargan las páginas de un proceso que son necesarias en cada momento. Un proceso pagina por el simple hecho de cargarse en memoria, por ello es normal que el parámetro que representa a las páginas cargadas en un sistema mantenga siempre en un valor mayor no nulo. Si un sistema empieza a estar algo falto de memoria, empiezan a escribirse páginas en disco (salvo que se trate de un sistema con el método copy-on-write, en cuyo se escribe en disco simplemente porque se ha modificado, o viceversa). Cuando el sistema está muy escaso de memoria, o bien cuando un proceso está vagueando, esperando a e/s (por ejemplo, entre dos pulsaciones de tecla), se le envía a disco; sólo en caso de pánico se recurre al swapping de desesperación, cuando un proceso ejecutándose se envía a disco. Si ocurre esto, tío, tienes un problema.

Las prestaciones de memoria, incluyendo memoria virtual, se vigilan con vmstat o sar –w y -p. Los parámetros a vigilar son page-in, pero sobre todo page-out y swap-out.

Cuando se detecta un problema, hay diversas técnicas para evitarlos. La que se le ocurre a uno inmediatamente es, caray, comprar más memoria; hoy en día va barata y hay que aprovechar el momento. Hay también otros modos de hacerlo no tan drásticos (u onerosos):

Un pequeño tutorial sobre lo que hay que hacer cuando se agotan los recursos nos lo proporciona esta página. Menciona sobre todo el uso de rlimit; en esta otra página mencionan DaemonTools, una serie de herramientas de control de procesos, que incluyen programas para limitar el uso de recursos de un proceso determinado. También en esta guía de tuning para Linux da unos cuantos consejos sobre qué cambiar y cómo


1. Examinar un sistema que tengamos a mano, y en el cual tengamos privilegio de administrador, cambiar alguno de los parámetros relativos a la memoria, y ver como influye en las prestaciones del sistema; para evaluarlo, usar un monitor antes y después del cambio.
2. Consultar en internet o en los manuales del sistema operativo cuáles son los parámetros relativos a la memoria modificables por el usuario y administrador, y decir qué posible impacto pueden tener en las prestaciones del sistema.

Aunque el subsistema gráfico tiene su importancia, no es algo de lo que el administrador del sistema se pueda preocupar, ya que afecta más a las prestaciones de un ordenador local que a las del sistema en general; lo mismo ocurre con impresoras, que siempre van a funcionar mal, así que no merece la pena preocuparse por ellas; lo que sí afecta las prestaciones del sistema en general son los discos duros, y en ellos nos vamos a fijar en este apartado.

Los discos duros incluyen tanto los locales como aquellos accesibles mediante NFS, el sistema más popular para acceso a filesystems remotos (junto con Samba, si la configuración incluye máquinas con Windows). La eficiencia de estos sistemas estará en tres factores diferentes: throughput por proceso, throughput total, y eficiencia en el almacenamiento.

El optimizar los primeros dos factores es hasta cierto punto compatible, si un sistema tiene unas buenas prestaciones por proceso, también lo serán las totales, pero no necesariamente. Un proceso suele acceder a un solo fichero en un solo disco duro, mientras que el sistema en total accede a muchos ficheros simultáneamente en muchos discos duros, o, lo que es peor, en el mismo. El que interese más uno u otro factor dependerá del uso prioritario de cada disco duro y del sistema en total.

El tercer factor, eficiencia en el almacenamiento, es incompatible con el throughput; si se trata de optimizar el throughput disminuye la eficiencia en el uso del disco. Por ejemplo, incrementar el tamaño del bloque hace que vaya más rápido a la hora de leer o escribir, pero aumenta el número de bytes que cada fichero ocupa, y viceversa. Sin embargo, UNIX tiene la ventaja de que diferentes filesystems pueden tener diferente tamaño de bloque.

Cada disco va enganchado a una controladora de disco que es determinante de sus prestaciones. En muchos casos, a cada controladora van conectados varios discos; cada uno de esos discos tiene que “compartir” la velocidad de transferencia de la controladora. A su vez, la controladora va conectada al bus del sistema. Todos estos elementos influirán en las prestaciones del disco.

Las dos controladoras más habituales hoy en día, y no sólo para discos duros, son la última versión de la SCSI (Small Systems Computer Interface), que creo que es la Ultra Wide SCSI y SCSI-3, y la EIDE (Extended Independent Drive Electronics), también llamada ATA (AT Attachment); la última es la Ultra ATA/100, o ATA-4, aunque hay también una especificación Serial ATA, que simplifica la conexión reduciéndola a 4 cables, en vez de los 20 o 30 actuales. Casi todos los ordenadores "personales" llevan alguna versión de la IDE, mientras que todas las estaciones de trabajo suelen llevar SCSI. En ambos casos, se pueden conectar varias unidades a cada controlador, hasta 10 en el caso de SCSI, y 4 en el caso de la IDE. El conectar diversos dispositivos al mismo conector habitualmente afecta las prestaciones del conjunto ya que las peticiones de lectura o escritura y su respuesta deben de viajar por el mismo conjunto de cables. En cualquier caso, un administrador tiene poca elección sobre el controlador a usar, salvo que si hay muchos discos duros conectados a un controlador, se puede pedir otro.

Últimamente se están poniendo de moda otro tipo de controladores: los USB y los FireWire (o IEEE 1394), dos tipos de buses serie que permiten conectar todo tipo de dispositivos externos al ordenador, y en particular discos duros. Tienen la ventaja de ser Plug'n'Play, es decir, nada más enchufarlos el sistema es consciente de ellos. Aunque actualmente son más productos de consumo que para servidores, es posible que en el futuro se popularicen.

En cuanto al segundo factor, el bus, sucede lo mismo: PCI es el más usado en el segmento de los PCs, y diferentes buses propietarios en los servidores y estaciones de trabajo. En algunas estaciones de trabajo hay diferentes buses; por ejemplo, PCI y alguno propietario, como Mbus, cada uno con sus características. La elección del bus al que se va a conectar el disco duro es previa a la compra del mismo, y de la controladora que va con él; pero en la mayoría de los casos tendrá uno de conformarse con lo que haya.

Asimismo, habrá que elegir a qué ordenador se van a conectar los discos duros; aunque el conectar todos los discos duros a un solo servidor hace la gestión mucho más fácil, el que cada grupo de trabajo tenga un disco duro normalmente aumenta las prestaciones. Cuando se haya tomado una decisión, y esté funcionando, el análisis de prestaciones del sistema nos revelará si la elección es adecuada o no.

Otro factor es la organización del sistema de discos duros: almacenamiento en red, RAID, o discos duros distribuidos en diferentes ordenadores. La organización distribuida tiene la ventaja de no crear cuellos de botella, mientras que el almacenamiento en red o en un sólo ordenador tiene más facilidad de mantenimiento.

Los siguientes factores son las características físicas del disco duro. Hay dos parámetros principales: la velocidad de transferencia, y el tiempo medio de búsqueda; ambas están relacionadas con la capacidad del disco. Habitualmente, a mayor capacidad, mayor velocidad de transferencia y menor tiempo medio de búsqueda. También están relacionados con la velocidad de rotación del disco duro; hoy en día hay discos que giran hasta a 10000 RPM, mientras que hace unos años todos giraban a 3600 RPM. La capacidad máxima actualmente viene a ser de unos unos cientos de GBytes. Para una guía actualizada, consultar la guía de Tom's Hardware de dispositivos de almacenamiento.

De esos dos, el más importante es el tiempo de búsqueda. El tiempo de búsqueda es bastante no lineal, y depende del sitio donde se encuentra la cabeza y donde tenga que ir; normalmente se especifica el tiempo mínimo de búsqueda. Esto es cierto principalmente en entornos multiproceso/multiusuario, donde es más habitual que el cabezal del disco esté saltando de allá pacá buscando diferentes ficheros, que el que tenga que leer un fichero grande y se le deje en paz mientras lo haga. Habitualmente, la tasa de tiempo empleado buscando con respecto al tiempo empleado transfiriendo es de 10 a 1; por eso es interesante que sea lo menor posible. Lo más habitual es que esté por debajo de los 10 ms., llegando a 6.3 ms. o incluso menos en algunos casos (por ejemplo, IBM Storage Systems Ultrastar 18XP).

En cuanto a la tasa de transferencia, aunque de ella hay que descontar toda la información de formateo y el tiempo que se tardaría en saltar de una pista a otra, suele ser un buen indicador de throughput para un solo proceso.

Con todo y con eso, puede haber diferencias considerables entre un disco duro y otro, dependiendo de la configuración, el tamaño de caché, la forma de "pegarse" al ordenador, e incluso la edad. Conviene considerar cuidadosamente todos los factores antes de decidirse.

En resumen, si hay que comprar un nuevo sistema de E/S, dado que hay poca elección en cuanto al controlador y al ordenador que hay que conectar, lo más importante es el tiempo mínimo de búsqueda. Para ver más información sobre el tema, ver el artículo de Epinions.

En la mayoría de los casos y de los sistemas operativos actuales, hay varios filesystems donde elegir; como mínimo, hay un filesystem "antiguo", que se usa por razones de compatibilidad, y uno "nuevo"; incluso puede darse el caso de que un mismo sistema operativo tenga diferentes filesystems, uno en cada versión, y que un mismo ordenador tenga diferentes filesystems en un mismo disco duro incluso. Ahí van algunos de ellos:

  1. Buscar comparativas entre prestaciones de diferentes filesystems y sacar conclusiones sobre su adecuación para alguna tarea en particular.

En cada partición suele haber un filesystems; y un sistema UNIX suele tener muchas particiones en cada disco, aparte de varios discos en cada sistema. Por ejemplo, suele haber particiones de swap, de usuarios y de root, pero puede haber muchas más: de alumnos y de profesores, por ejemplo. Hay que seguir unas cuantas reglas a la hora de distribuir ls particiones:

A menos que uno vaya a manejar un sistema grande, estos consejos no son necesarios, pero uno nunca sabe cuando se va a encontrar con un sistema grande, o el sistema va a crecer tanto que se va a convertir en grande.

La herramienta que se usa para esto es iostat o sar –d (recordar que, en algunos sistemas como Solaris o Linux, las herramientas que recogen información para sar no están activadas por defecto). Iostat da un informe que, entre otras cosas, indica cuánto se ha leído y escrito en cada disco duro físico, y cuántas transacciones, o peticiones de lectura/escritura, ha habido.

Idealmente, el número de lecturas y escrituras, y el número de transacciones debe de estar repartido uniformemente entre todos los discos; pero lo más habitual es que alguno de los discos se lleve toda la carga, y otros estén la mayor parte del tiempo quietos. En caso de que eso suceda, lo que se debe de hacer es reequilibrar la carga, de la forma siguiente:

Es un axioma de la Naturaleza que, igual que ninguna familia llega a fin de mes por mucho que gane, cualquier disco duro por grande que sea acaba llenándose. Algunos de los trucos usables para ahorrar espacio de disco son los siguientes:

Hay principalmente dos herramientas que sirven para ver cómo se está usando el espacio: df, que muestra todos los filesystems que hay montados, el espacio que tienen y el disponible, y el du, que muestra cuánto ocupan todos los ficheros y directorios que descienden de uno determinado, incluyendo directorios de usuario.

El programa que hemos visto antes, limit, permite también limitar el tamaño máximo de fichero y el de los coredumps; permitiendo limitar incluso los coredumps a tamaño 0. Lo primero es un poco cafre, porque puede que hagan falta ficheros grandes, y lo segundo puede ser peligroso, si se usan los cores para depurar, pero, qué diablos, a veces un administrador del sistema tiene que tomar decisiones difíciles.

Por ejemplo, este tutorial de Sun contiene una serie de reglas que se pueden cambiar en un sistema Linux o Solaris, todas dentro de /proc/sys/fs. Todas las opciones de este filesystem están en este tutorial. En este tutorial también explica como cambiar diferentes parámetros sobre la marcha, tanto del sistema de ficheros como del subsistema SCSI.

  1. Consultar los parámetros físicos de los discos duros del sistema personal, y decir si la configuración maestro/esclavo que se está usando es la más adecuada.
  2. Consultar en internet o en los manuales del sistema operativo cuáles son los parámetros relativos al subsistema de entrada/salida modificables por el usuario y administrador, y decir qué posible impacto pueden tener en las prestaciones del sistema.
  3. Evaluar para el sistema personal, y la distribución de ficheros que hay, si el tamaño de cluster sería el más adecuado. Evaluar si, cambiando el tamaño de cluster, se ocuparía menos espacio.

Se puede medir el porcentaje de uso del fichero de paginación, porcentaje de uso de disco y demás. Puede ser que en un servidor haya algún problema, pero lo más normal es que no lo haya. En caso de que el archivo de paginación se use más del 90% del tiempo, hay algún problema. En algunos casos, usar una controladora de disco con caché puede mejorar el asunto.

A partir de la guía encontrada en PCGuide, se puede hacer lo siguiente para mejorar las prestaciones de un disco duro:

En el libro Web Performance Tuning dan una serie de consejos para optiizar las prestaciones de un servidor web:

Otro documento indica otra serie de posibles mejoras, incluyendo mejoras del sistema de red del que, al fin y al cabo, depende el servidor web.


1. Sobre un servidor web ha instalado, tratar de optimizar el número de peticiones concurrentes, el tiempo de respuesta, y el ancho de banda.

En el artículo "Optimize Windows XP", de Diciembre de 2001, vienen una serie de consejos para optimizar las prestaciones de Windows XP.


1. Sobre un sistema que se tenga a mano, llevar a cabo una monitorización usando las técnicas explicadas en este tema, proponer mejoras, llevarlas a cabo, y volver a monitorizar indicando dónde han impactado las mejoras.

Portada del libro System Performance TuningSystem Performance Tuning, 2nd Edition, de Gian Paolo Musumeci y Mike Loukides, O'Reilly. Sustituye a la edición anterior, que estaba un tanto obsoleto, pero que contiene todas las técnicas básicas para analizar las prestaciones de los diversos subsistemas de un ordenador: memoria, disco, red. Está actualizado hasta la versión 2.4 del kernel de Linux, y las últimas versiones de Solaris; todas las herramientas y pruebas están presentadas sobre estas dos plataformas. El libro está disponible en Safari y también en la biblioteca de la ETSII (la primera edición).
Portada del libroUnderstanding the Linux Kernel, de Daniel P. Bovet y Marco Cesati, de O'Reilly. Un libro que analiza uno por uno las diferentes partes del kernel de Linux. Es un libro muy reciente, que cubre la versión 2.2 del kernel, con pequeñas observaciones al final de cada capítulo sobre el kernel 2.4. Especialmente interesantes para esta asignatura son los capítulos sobre procesos (capítulo 3) y sobre scheduling de procesos (capítulo 10), donde se explican las estructuras de datos usadas para la gestión de procesos, y los algoritmos para asignación dinámica de prioridad a los procesos, incluyendo su ejecución en sistemas multiprocesador.
Es un libro imprescindible para entender la labor del administrador del sistema que debe, al fin y al cabo, entender el kernel de Linux para que su sistema le saque el máximo partido posible. Por supuesto, es sumamente útil para los que estén interesados en crear sus propias versiones del kernel, o simplemente usarlo como documentación para una asignatura de sistemas operativos.
Portada del libroThe art of computer systems performance analysis: Techniques for experimental design, measurement, simulation and modelling, Raj Jain, Wiley, 1992. Por la fecha de publicación, se ve que tiene el mismo problema que el primero; sin embargo, tiene un enfoque ameno y completo al problema del análisis de prestaciones.
Portada del libroWeb Performance Tuning: Speeding Up the Web (O'Reilly Nutshell) by Patrick Killelea (2nd edition); es un poco básico y pierde mucho tiempo en cosas tales como optimizar el cliente, pero tiene buenos consejos sobre como optimizar las prestaciones de un servidor web. La edición anterior está disponible online en Safari (completa).

También se puede encontrar información por la misma Internet, aparte de la mencionada en el texto. Algunos sitios:

Licencia de Creative Commons
Esta obra está bajo una licencia de Creative Commons.

Realizado por
Juan Julián Merelo Guervós jmerelo at geneura.ugr.es
Depto de Arquitectura y Tecnología de Computadores
Universidad de Granada
URL:http://geneura.ugr.es/~jmerelo/DyEC/Tema3/DyEC-Tema3.html