D3 gestión de sistemas operativos

TFC: ARQUITECTURA DE COMPUTADORES
Y SISTEMAS OPERATIVOS
MEMORIA
GESTIÓN DE PROCESOS EN LOS
SISTEMAS OPERATIVOS
ALUMNO: Francisco Javier Serrano Castaño
CONSULTOR: Francesc Guim Bernat

TFC: Arquitectura de Computadores y Sistemas Operativos
2
Resumen
En los últimos años se puede apreciar cómo, dentro de los tres Sistemas Operativos más
utilizados para computadoras personales, hay una especie de batalla por presentar cual
ofrece mejores prestaciones. Estos tres sistemas mencionados son Windows 7 de
Microsoft [8], Ubuntu de Linux [6] y Mac OS X de Apple [7].
Por ello en este Trabajo Fin de Carrera (TFC) se realizará una comparación de los tres
sistemas operativos mencionados respecto al rendimiento que ofrecen sobre el servidor
web Apache instalado en cada uno de ellos. Antes de realizar dichas pruebas, se
describirán cómo cada uno de los sistemas operativos maneja la gestión de procesos,
gestión de memoria, etc. Se realizará una descripción de cada uno de ellos respecto
sobre cómo realizan dichas funciones. Con ello se pretende tener una base sobre la cual
fundamentar posteriormente los resultados obtenidos de las pruebas con los procesos
que genere el servidor web Apache [11].
Cabe mencionar que la instalación de los sistemas operativos será llevada a cabo a
través de máquinas virtuales, utilizando para ello como software de creación y gestión
de las mismas VMware [13]. Se utilizará dicho software por la experiencia y robustez
para albergar a los tres sistemas operativos a evaluar. Se ha elegido este tipo de
instalación debido al creciente auge de la instalación de equipos virtuales, por lo que se
podrá comprobar también el rendimiento de cada uno de los sistemas instalados en
dichas máquinas virtuales.
La realización de la práctica se utilizará en concreto los siguientes Sistemas Operativos:
Windows 7 Profesional, Ubuntu 10.10 y Mac OS X 10.6. En cada uno de los sistemas
se configurará el servidor Web Apache, al que se le realizarán una serie de test con los
que se podrá comprobar las diferencias de rendimiento de unos sistemas a otros.

3
Índice General
1- Introducción
1.1 Objetivos del TFC
1.2 Enfoque del TFC
1.3 Planificación del TFC
1.3.1 Recursos de software y hardware
1.3.2 Tareas y coste del proyecto
2- Sistemas Operativos
2.1 ¿Qué es un Sistema Operativo?
2.2 Clases de Sistemas Operativos
2.3 Máquina Virtual
3- Gestión de Procesos
3.1 Definición
3.2 Estados de un proceso
3.3 Planificación de un proceso
3.4 Creación y destrucción de procesos
4- Gestión de Memoria
4.1 Memoria principal
4.2 Memoria virtual
4.2.1 Traducción de página virtual a física
4.2.2 Paginación
4.2.3 Segmentación
4.3 Gestión de Memoria en UNIX
4.4 Gestión de Memoria en Windows

4
5- Implementación
5.1 Hypervisor
5.1.1 Concepto de Hypervisor
5.1.2 Instalación del Hypervisor
5.1.3 Creación y configuración de máquinas
virtuales
5.1.4 Instalación del Sistema Operativo
5.2 Sistemas Operativos
5.2.1 Configuración
5.2.2 Servidor Web apache
5.2.2.1 Conceptos
5.2.2.2 Instalación y configuración
5.3 Benchmarking
5.3.1 Descripción y tipos
5.3.2 Instalación y configuración
6- Evaluación de los Sistemas Operativos
6.1 Test inicial
6.2 Cambios de configuración
6.3 Test final
7- Análisis de resultados
8- Conclusiones
9- Bibliografía y enlaces

5
1. Introducción
1.1. Objetivos del TFC
El objetivo principal del trabajo es la de realizar un estudio comparativo de los
diferentes Sistemas Operativos a estudiar respecto al rendimiento que ofrecen respecto
a un mismo problema. En este caso se trata de los sistemas; Windows 7 Profesional,
Ubuntu 10.10 y Mac OS X 10.6.
El problema a tratar será ver la respuesta del servidor web apache ante un
benchmarking [24], es decir, utilizar una aplicación que mediante técnicas de fuerza
pueda medir el rendimiento de ciertas aplicaciones o hardware, en este caso de la
aplicación Apache, y compararlo entre los tres sistemas operativos mencionados. Las
aplicaciones que se utilizarán para realizar el benchmarking son: JMeter [25] y ab
[26].
1.2. Enfoque del TFC
Este proyecto se inicia con una fase teórica en la que se realizará una breve
descripción de distintos aspectos de dicho trabajo, entre los cuales nos encontramos la
definición de sistema operativo y las clases de sistemas que vamos a tratar en el
trabajo. Además se habla de qué es una máquina virtual, ya que en este trabajo los
sistemas a utilizar serán instalados sobre máquinas virtuales.
Otros aspectos a destacar, son los relativos a la gestión de procesos y gestión de
memoria por parte de los sistemas a tratar. Se explicarán en qué consiste esta gestión y
cómo realiza la misma cada uno de los sistemas operativos, por lo que se puede ir
realizando una primera comparación de los sistemas respecto al tratamiento que cada
uno realiza en su funcionamiento o procesamiento de tareas.
En una segunda fase más práctica, se realizará la instalación de un Hypervisor o
monitor de máquina virtual, en este caso del Hypervisor VMware, en una máquina
para posteriormente crear las máquinas virtuales donde se instalarán cada uno de los
sistemas operativos a analizar.
En estos sistemas operativos tendremos que instalar el servidor web apache, que
será el proceso que medirá el rendimiento de los mismos. Este servidor será objeto de
distintas configuraciones para ver los cambios de rendimiento producidos en el mismo.

6
Para medir el rendimiento del servidor web Apache se utilizarán herramientas de
benchmarking [24]. Estas herramientas serán instaladas y configuradas en un equipo
distinto al utilizado anteriormente para realizar las mediciones de rendimiento de los
mismos.
En una última fase, se analizarán los resultados obtenidos en los test, y se
realizarán las conclusiones pertinentes.
1.3. Planificación del TFC
1.3.1 Recursos de hardware y software
En este apartado se detallan los recursos necesarios para llevar a cabo el
trabajo. Respecto al hardware, necesitamos lo siguiente:
- Dos PCs con un equipamiento similar al siguiente: procesador Core 2
Duo o similar, 4 GB memoria RAM, 160 GB de HD (Disco duro),
tarjeta de red mínimo a 100 MB/s. El coste de dichos equipos rondan los
450 €
- Conexión entre los dos PC, ya sea mediante un cable cruzado conectado
directamente sobre las tarjera de red de los dos equipos, es la manera
más económica, o bien a través de un conmutador o switch.
Respecto al software necesario:
- El PC que realizará el test tendrá instalado Windows 7 Profesional, con
un coste de 278 €.
- El PC con las máquinas virtuales tendrá instalado un Hypervisor sobre
Windows 7 Profesional (coste 278 €), se va a utilizar VMware
WorkStation 7 [16], debido a su potencial, compatibilidad con los
sistemas operativos a analizar. Coste 153€.
- Los sistemas operativos que se analizarán; Windows 7 Profesional,
Ubuntu 10.10 y Mac OS X 10.6. Excepto Ubuntu los otros dos sistemas
son propietarios, con un coste aproximado de 278 € en el caso de
Windows y 29€ en el caso de MAC OS X 10.6.
- Servidor web Apache [11], que será el proceso a analizar en cada uno de
los sistemas, es una aplicación gratuita.

7
- Las herramientas de Benchmarking; JMeter [25] y ab [26]. Todas las
elegidas son gratuitas y relacionadas con Apache.
1.3.2 Tareas y coste del proyecto
En este apartado se va a exponer las tareas en las que consta el proyecto, así
como el coste en tiempo empleado en cada una. Se ha estimado que el coste por
hora de trabajo es de 50 €/h, en el cual se ha incluido las licencias, consumo
eléctrico y coste de la persona/h. En el mismo no se ha contemplado el coste de
hardware de los equipos, ya que este puede variar según modelos.
- Creación del plan de trabajo (total 10 horas). Esta fase considerada como
una de las más importantes del mismo, ya que una vez elaborada
correctamente nos servirá como guía para el resto del trabajo. En la misma
se realiza una búsqueda superficial de información para tener claro el
contenido que va a tener dicho trabajo. A esta fase corresponde todo el
apartado Introducción del proyecto.
- Documentación (Total 5 horas). En esta fase se realiza la búsqueda de
documentación necesaria para el proyecto, la cual quedará reflejada en el
apartado de bibliografía y enlaces.
- Comparación teórica de los Sistemas Operativos (Total 20 horas). En esta
fase se hará mención a todos los aspectos técnico-teóricos que expliquen
qué es un sistema operativo, y como cada uno de ellos gestionan los
procesos, memoria, archivos de sistema, etc.
- Instalación y configuración del PC con Hypervisor. (Total 6 horas). Esta
tarea consta de la instalación del equipo donde se instalarán las máquinas
virtuales. Una vez se instala el sistema operativo Windows 7 Profesional, se
instalará el Hypervisor VMware WorkStation 7, tras el cual se crearán 3
máquinas virtuales en cada una de las cuales se instalará uno de los sistemas
a evaluar.
- Configuración de Apache y testeo de los sistemas (Total 30 horas). Esta fase
consta de la instalación de la aplicación Apache en cada una de las
máquinas virtuales y la configuración de las mismas para poder ser
evaluadas desde otro equipo. Antes de comenzar a realizar las pruebas se ha
de configurar el equipo con las herramientas de benchmarking. A lo largo de

8
esta fase se realizarán distintas pruebas, ya que se harán cambios en la
configuración del servidor web apache para ver como repercuten dichos
cambios en el rendimiento del mismo.
- Estudio y análisis de las pruebas (Total 10 horas). Una vez obtenidos los
resultados de los test realizados en cada uno de los sistemas, se compararán
y se analizarán, concretando quién ha tenido mejores resultados y en qué
condiciones.
- Elaboración de la memoria (Total 10 horas). Se recopilarán todos los datos
y documentos realizados hasta la fecha, revisando la escritura y presentación
de los mismos, de manera que quede maquetada para su entrega.
- Creación de la presentación (Total 10 horas). Se realizará el documento de
presentación del TFC, donde se plasmarán las ideas más importantes del
trabajo.
- Revisión y entrega. Durante la última semana, antes de la entrega del TFC,
se realizará una última revisión en busca de fallos o mejoras en el mismo, y
se procederá a su entrega final.

9
Diagrama de GANTT

10
2. Sistemas Operativos
2.1. ¿Qué es un Sistema Operativo?
Un sistema operativo se puede definir como la capa de software que equipa a
las computadoras, cuya labor es la de administrar y gestionar todo el hardware que
interactúa en la misma y proporcionar una interfaz sencilla a los programas para
comunicarse con dicho hardware, entendido éste como los procesadores, memoria,
discos duros, teclado, pantalla, impresoras, interfaz de red y todo tipo de dispositivo de
E/S.
Se puede decir por tanto que el sistema operativo se encuentra entre el hardware
y las aplicaciones de usuario (navegadores web, programas de ofimática, etc.)
proporcionado así a los programadores de dichas aplicaciones un conjunto de
instrucciones conocidas como llamadas al sistema, para trabajar con más comodidad,
de lo contrario los programadores tendrían que realizar dichas tareas en un lenguaje de
programación que se comunicara directamente con los dispositivos, siendo éste
conocido como lenguaje de máquina, lo que complicaría enormemente la labor de
estos.
Respecto a la gestión del hardware que realiza el sistema operativo, consiste en
administrar los recursos de una computadora cuando dos o más programas que se
ejecutan simultáneamente requieren usar el mismo recurso (tiempo de CPU, memoria,
etc.), por lo que será el sistema operativo el encargado de ordenar y compartir dichos
elementos en dos formas: en el tiempo y en el espacio. Cuando un recurso se
multiplexa (comparte) en el tiempo, diferentes programas o usuarios se turnan en su
uso, un ejemplo de ello es la cola de impresión que genera el sistema operativo
indicando quien imprime primero y quien a continuación. El otro tipo de
multiplexación es en el espacio, en este caso lo que ocurre es que el sistema reparte el
recurso entre los usuarios y programas. Un ejemplo típico es el uso de la memoria
principal, donde, dependiendo del tamaño de la misma, pueden residir distintos
programas a la vez a la espera del uso de la CPU.

11
2.2. Clases de Sistemas Operativos
En este punto se realizará una mención por los distintos tipos de Sistemas
Operativos, dependiendo del número de aplicaciones que ejecutan, del número de
usuarios que interactúan, del número de procesadores que manejan o dependiendo de
la estructura. A continuación se enumeran los sistemas mencionados:
 Según la utilización de los recursos. Si un sistema operativo se ejecuta en una
computadora con un solo procesador se clasifican en sistemas monoprogramados
y multiprogramados. Sin embargo si tiene varios procesadores se habla de
sistemas multiprocesamiento.
- Sistema monoprogramado. Sólo se permite la ejecución de un programa en el
sistema, por lo que el programa se carga en memoria y permanece en ella
hasta su finalización.
- Sistema multiprogramado o multitarea. Estos sistemas pueden ejecutar
simultánea varias tareas y de varios usuario. El sistema operativo mantiene
varios trabajos en la memoria, y mientras uno está a la espera de realizar
alguna tarea, por ejemplo la terminación de una operación de entrada/salida
(E/S), ya sea el presionar una tecla u otra tarea, el sistema operativo
selecciona otro trabajo para que la CPU lo ejecute y esta última no quede
vacía de trabajo mientras estos esperan su ejecución. Hoy en día todos los
sistemas operativos son multitarea.
- Sistema multiprocesador. Estos sistemas son aquellos que pueden manejar
varios procesadores, con lo que se alcanza un mayor rendimiento ya que al
tener más procesadores podemos realizar más tareas al mismo tiempo, aunque
hay que decir que este aumento no es proporcional al aumento del número de
procesadores. A este tipo de sistema también se le llama computadoras
paralelas o multicomputadoras, ya que cada procesador tiene una copia del
sistema operativo, y éstas se comunican entre sí para el manejo de las tareas,
repartiéndose las mismas entre los procesadores, es decir, una tarea es
ejecutada en proporción por todos los procesadores.
 Según la interactividad. En este caso se habla de los sistemas dependiendo del
tipo de trabajo y los servicios que se presta a los usuarios se habla de sistemas de
procesos por lotes, sistemas de tiempo compartido y sistemas de tiempo real.

12
- Sistemas de procesamiento por lotes (Batch). En este tipo de sistemas no
existe intervención del usuario durante la ejecución de los trabajos. Cada
trabajo consiste en una relación de pasos secuenciales, que al juntarse forman
un lote. Estos procesamientos son largos y no tienen límite de tiempo en su
ejecución.
- Sistemas de tiempo compartido. En este tipo de sistemas los procesos se
ejecutan de manera simultánea mientras la CPU conmuta entre ellos, de
manera que el usuario es ajeno a la misma. En estos sistemas los usuarios sí
pueden interactuar con los programas durante su ejecución.
- Sistemas de tiempo real. Se caracterizan porque maximizan el tiempo en el
que se manda la información, por ello se utilizan para procesos delicados,
como por ejemplo la ejecución por parte del brazo de un robot en una planta
de ensamblaje de vehículos. Dicho robot debe obtener la información de
ejecución dentro de unos márgenes estrictos de tiempo, ni antes ni después.
 Según el número de usuarios. En este caso se habla de los sistemas dependiendo
del tipo de trabajo y los servicios que se presta a los usuarios se habla de
sistemas de procesos por lotes, sistemas de tiempo compartido y sistemas de
tiempo real.
- Sistema operativo de computadora personal. Se puede también denominar
sistema monousuario. Atiende al número de usuarios que utilizan dicho
sistema al mismo tiempo. En el caso de los monousuario hasta que la persona
que está utilizando el equipo no termina, éste no puede ser utilizado por otra.
El sistema operativo de computadora personal tiende a ser monousuario, ya
que es un sistema enfocado a maximizar la comodidad del usuario y a
responder con rapidez a las necesidades de éste. Como ejemplo actual de este
sistema podemos mencionar a Windows 7, que excepto en algunas versiones
mediante la herramienta de terminal server se puede convertir en
multiusuario, la mayoría es monousuario.
- Sistema operativo servidor o multiusuario. Al contrario que el anterior, en
este sistema concurren más de un usuario de forma simultánea desde
diferentes ubicaciones. Por ejemplo el caso de los servidores web, los cuales
sirven las páginas alojadas en los mismos a través de internet a todo aquel que
las visite. Entre los sistemas operativos de servidor encontramos a UNIX,
Windows Server y Linux.

13
 Según el número de computadoras. Dependiendo del número de computadoras
que formen parte del sistema, se puede hablar de sistemas centralizados o sistemas
distribuidos.
- Sistemas centralizados. Este tipo de sistemas es aquel que utiliza los recursos
de una sola computadora, como es la memoria, CPU, discos, periféricos. Este
tipo de sistema planteaba un problema, y es que cuando se interconectaban
ordenadores a uno principal, cuando este último requería un cambio de
hardware para aumentar su capacidad, ello era más costoso que añadir nuevos
computadores.
- Sistemas distribuidos. Como lo define Tanenbaum [3], “Un sistema
distribuido es una colección de computadoras independientes que aparecen
ante los usuarios del sistema como una única computadora”.
En este tipo de sistemas se utiliza al mismo tiempo los recursos de los
distintos equipos, ya bien sea el hardware o el software de los mismos, por lo
que las computadoras se comunican entre sí a través de distintos medios de
comunicación, como pueden ser líneas de alta velocidad o líneas telefónicas.
Este tipo de sistemas puede abarcar desde unas pocas computadoras hasta
miles o millones de ellas, enlazadas a través de internet. Estos recursos que
son compartidos son manejados por un gestor de recursos, que es un software
que se encarga de controlar dichos recursos.
 Según la estructura del sistema operativo. En este caso se encuentra los distintos
sistemas dependiendo del diseño interno de los mismos. Entre ellos encontramos
los sistemas monolíticos, los sistemas en capas, las máquinas virtuales y el
sistema cliente-servidor.
- Sistemas monolíticos. Son sistemas pequeños, sencillos y limitados. No
tienen una estructura definida, sino que todos sus componentes se encuentran
agrupados en un único programa. Cada conjunto de procedimientos puede
invocar a cualquiera de los otros procedimientos. Un ejemplo de este tipo de
sistemas es el sistema MS-Dos.
- Sistema por capas. El sistema se organiza como una jerarquía de capas, donde
cada capa ofrece una interfaz a la capa superior, y sólo utiliza los servicios
que ofrece la capa inferior. Cada capa tiene funciones específicas, así cada
capa se encarga de una parte del sistema operativo.

14
- Sistema de máquina virtual. Este sistema será tratado de una manera más
amplia en el siguiente punto 2.3.
- Sistema cliente-servidor. El sistema consiste en un conjunto de módulos
autónomos, los cuales ponen a disposición de los demás una serie de servicios
o competencias. Es decir, cada uno de los módulos actúan como servidores
que atienden las peticiones de otros módulos que actuarían como clientes.
Este tipo de sistema es muy apropiado para los sistemas distribuidos.
2.3. Máquina Virtual
Este TFC, como ya se ha descrito, versa sobre las diferencias de gestión entre
sistemas operativos, pero estos van a ser instalados en máquinas virtuales creadas al
efecto, por lo que cabe hacer una reseña del funcionamiento de dichas máquinas
virtuales.
El concepto de máquina virtual surge con el sistema VM/3701
de IBM, en el que
se separa las dos funciones que proporciona un sistema de tiempo compartido o
multiusuario, como son la multiprogramación y la abstracción del hardware.
El corazón del sistema de creación de las máquinas virtuales es conocido como
monitor de máquina virtual, y se ejecuta sobre el hardware proporcionando varias
máquinas virtuales a la siguiente capa de software. Se puede decir que estas máquinas
virtuales son copias exactas del hardware desnudo donde se incluyen los recursos
principales de una computadora, como es el kernel, dispositivos E/S, interrupciones,
memoria principal, etc. A continuación se muestra la estructura de dicho sistema2
.
Cada máquina virtual puede ejecutar cualquier sistema operativo debido a la
circunstancia comentada de que cada una es una copia exacta del hardware. En el caso
de la figura anterior se puede apreciar como distintos sistemas operativos
1
Se puede encontrar más información detallada en la web de IBM http://www.vm.ibm.com/
2
Esta figura ha sido extraída del libro Tanenbaum Andrew S.: Sistemas Operativos Modernos. Ed. Prentice Hall
Figura 1 Estructura del VM/370

15
monousuarios (CMS, Sistema Monitor de Conversaciones), cuando realizan una
llamada al sistema por medio de algún programa, ésta salta al sistema operativo de la
propia máquina virtual, no a la VM/370 como hubiera ocurrido en una máquina real,
entendiendo que esta sería la capa de software por encima de la capa de hardware de la
computadora. A continuación el CMS emite las instrucciones de E/S necesarias para
ejecutar la llamada, el sistema VM/370 recoge estas instrucciones y las ejecuta como
parte de su simulación de hardware real.
Esta idea de la virtualización también se encuentra en la ejecución de programas,
en lo que se conoce como máquinas virtuales de proceso o máquinas virtuales de
aplicación. Fue Sun Microsystem [21] quién al inventar el lenguaje de programación
Java, también inventó la máquina virtual java (JVM) [22]. Consiste en que al
ejecutarse una aplicación en este lenguaje, las instrucciones no son ejecutadas por el
procesador ni por el hardware de la máquina, sino que son ejecutadas por un software,
en este caso por la JVM que es una máquina virtual, que las interpreta, y lleva a cabo
una acción sobre el hardware a partir de estas. Esta característica de ser portable es
fundamental, ya que se puede ejecutar en cualquier máquina que tenga un intérprete de
JVM sin necesidad de cambio del código, aun ejecutándose en distintos sistemas
operativos, e incluso acceder vía internet a aplicaciones remotas y ejecutarse.
Otra máquina virtual de proceso muy utilizada es la proporcionada por el
entorno .Net de Microsoft [23], que recibe el nombre de Common Language Runtime.
Respecto a las máquinas virtuales de sistema podemos decir que hay dos tipos o
clases que son las más comunes; las que se ejecutan directamente sobre el hardware o
las que se ejecutan sobre un sistema operativo.
La diferencia entre una u otra es que en la primera no tenemos un sistema
operativo entre las máquinas virtuales y el hardware, en cambio en las segundas, las
máquinas virtuales se sitúan en un nivel superior al del sistema operativo que alberga
el monitor de máquinas virtuales (VMM). Vemos dichas diferencias en las siguientes
figuras3
2 y 3.
3
La fuente de los gráficos es del TechNet Magazine: http://64.4.11.252/es-
es/magazine/2008.10.hyperv.aspx

16
Dentro de los distintos VMM o Hypervisor los más usuales son: VMware en las
versiones ESXi [15] y Workstation [16], XEN de Citrix [17], Virtual Box de Sun [18], Virtual
PC 2007 de Microsoft [19], Hyper V de Microsoft [20].
Estas máquinas virtuales se utilizan hoy en día para diferentes entornos, los más
utilizados son los entornos de desarrollo o pruebas, pero también se están utilizando cada vez
más para entornos en producción, así se puede encontrar por internet como muchos ISP
ofrecen sus servicios de hosting mediante servidores virtuales. También se utiliza la
virtualización para consolidar servidores en una sola máquina con suficientes recursos para
ello, así tendremos las máquinas aglutinadas en una misma computadora, a las cuales se podrá
hacer una copia de seguridad del sistema completo, ya que este se compone de un solo fichero.
Este último punto junto con la posibilidad que nos ofrecen las máquinas virtuales de ser
traspasadas de un host a otro con el mismo tipo de VMM, nos ofrecen un entorno en el que la
pérdida de un servicio gestionado por una máquina virtual puede ser mínimo, al poderse
restaurar dichas máquinas virtuales de una manera fácil entre los distintos hosts. Otro de los
beneficios que proporcionan las máquinas virtuales y por lo que son elegidas es el ahorro de
energía. No consume lo mismo una máquina física con 10 máquinas virtuales que 10
máquinas físicas.
Otro tipo de virtualización es la llamada virtualización a nivel de sistema operativo.
Esta técnica consiste en dividir una computadora física en varias con compartimentos
independientes en los cuales se puede instalar un sistema operativo diferente. Así el sistema
operativo de la máquina virtual comparte el mismo kernel que el sistema usado para
implementar dichas máquinas virtuales. Las aplicaciones de un sistema operativo que corren
en una máquina virtual, lo ven como un sistema autónomo. Dentro de esta categoría nos
encontramos distintos ejemplos: Virtuozzo [28], Linux-VServer [29], Solaris containers [30],
OpenVZ [31] y FreeBSD Jails [32].
Podemos decir por tanto que la virtualización es cada vez más utilizada y más extendida
en una amplia variedad de ámbitos, desde un usuario que quiere probar distintos sistemas
Figura 2 Monitor sin Sistema Operativo Figura 3 Monitor con Sistema Operativo

17
operativos hasta llegar a algo muy de moda como es el cloud computing (computación en la
nube), cuyos servidores están cada vez más virtualizados.
Debido a este interés por la virtualización de servidores, se ha decidido utilizar
máquinas virtuales para ver no sólo el rendimiento de los sistemas operativos ante un
problema dado, sino también como estos responden siendo instalados en máquinas virtuales.
3. Gestión de procesos
3.1. Definición
Utilizando la definición dada en el material de la asignatura Sistemas Operativos se va a
explicar qué es un proceso. La definición es la siguiente: “Un proceso es básicamente un
entorno formado por todos los recursos necesarios para ejecutar programas. Desde el
punto de vista del SO, un proceso es un objeto más que hay que gestionar y al cual
hay que dar servicio”4
.
Podemos decir que un programa es una entidad pasiva, en tanto en cuanto es un
conjunto de instrucciones de código máquina y datos almacenados en un ejecutable. Mientras
que un proceso sería la ejecución de ese programa, es decir, el programa en acción. Esto indica
que los procesos son dinámicos, están en constante cambio debido a estos recursos necesarios,
ya que al intentar realizar algún tipo de acción puede ser que tenga que permanecer a la espera
de que dicho recurso esté disponible, por ejemplo una petición de lectura del disco duro, y que
el brazo lector del disco duro lo esté utilizando otro proceso.
Al igual que las instrucciones de programa, los procesos incluyen los contadores de
programa que indican la dirección de la siguiente instrucción que se ejecutará de ese procesos
y los registros de CPU, así como las pilas que contienen datos temporales, como son los
parámetros de subrutina, las direcciones de retorno y variables locales. Los procesos también
contienen una sección de datos con variables globales y memoria dinámica. Todo ello permite
gestionar de una manera más eficaz los procesos en los sistemas operativos multiprocesos, ya
que cada proceso es independiente, por lo que el bloqueo de uno no debe de hacer que otro
proceso en el sistema se bloquee.
En estos sistemas operativos multiproceso se intenta maximizar la utilización de la
CPU, por lo que los procesos se ejecutan simultáneamente en la CPU y sólo quedan a la espera
de ejecución si requieren de algún recurso del sistema que esté ocupado en ese momento, en
cuanto obtiene dicho recurso podrá ejecutarse de nuevo. Todo este proceso de gestión lo
realiza el sistema operativo, por lo que es el que decide si un proceso es más prioritario que
4
Definición dada en el punto 1 del módulo 6 (La gestión de procesos) dentro de la asignatura Sistemas Operativos.

18
otros. Es el programador el que decide esta prioridad, por ejemplo en el caso de Linux se
utiliza un número en la programación de estrategias para garantizar la equidad de los procesos.
Cada proceso se representa en el sistema operativo con un bloque de control de proceso
(PCB, Process Control Block). En este PCB se guardan una serie de elementos de información
de los mismos. Estos elementos son: el identificador del proceso, el estado del proceso,
registros de CPU (acumuladores, punteros de la pila, registros índice y registros generales),
información de planificación de CPU (prioridad de proceso, punteros a colas de planificación,
etc.), información de gestión de memoria, información de contabilidad (tiempo de uso de
CPU, números de procesos, etc.), información de estado de dispositivos E/S (lista de archivos
abiertos, etc.).
3.2. Estados de un proceso
En un sistema multiprogramado o multitarea donde existen muchos procesos y un
procesador, puede ocurrir que en un momento dado sólo se ejecute un proceso o varios y los
demás estén esperando a ser procesado o esperen la finalización de una operación de E/S. Los
pasos por los que puede pasar un proceso se pueden representar con un diagrama de estado
como el de la figura5
4. Así se puede apreciar que a medida que un proceso se ejecuta va
cambiando de estado dependiendo de las preferencias que cada uno tengan asignadas, por lo
que será el procesador el que se encargue de ejecutar unos u otros.
Cómo se aprecia en la imagen 4 los estados por los que puede pasar un proceso
son los siguientes:
5
Diagrama obtenido del material de la asignatura Sistemas Operativos (módulo 6. Gestión de procesos)
Figura 4 Diagrama de Estados de un proceso

19
- Nuevo. En los sistemas operativos hay varias razones por las que se crea un
proceso. Entre éstas se pueden destacar; la inicialización del sistema, cuando se
arranca el sistema se generan una serie de procesos ya bien sean para interactuar
con el usuario o procesos en segundo plano con una función específica, como
por ejemplo el aceptar la solicitud de una página web que está en dicha máquina;
ejecución de una llamada al sistema por parte de otro proceso, un proceso puede
requerir la descarga de ficheros, por lo que serán otros procesos los que se
encarguen de ubicar el archivo o archivos en la ubicación específica; por medio
de la acción de un usuario, por ejemplo al hacer doble clic en un icono; mediante
el inicio de un trabajo por lotes.
Una vez el proceso ha sido creado queda a la espera de ser admitido, por lo que
si es así pasaría a estado preparado o en caso contrario terminaría dicho proceso.
- Preparado (ready o listo). Un proceso en este estado está esperando a que se le
asigne un procesador. Como se puede apreciar en la figura 4, un proceso en este
estado puede, o bien finalizar, lo que ocurriría por la acción de otro proceso o
por algún acontecimiento externo, o bien el proceso pasa al estado ejecución, ya
que el gestor de procesos le asigna una CPU para ser ejecutado.
- Ejecución (run). El proceso en este estado está en la CPU ejecutando
instrucciones. Puede ocurrir tres situaciones; que el proceso ejecute todas las
instrucciones hasta su última línea de código y finaliza; pasa a estado bloqueado
(wait) por que espera una acción externa como la entrada de información por
teclado; o bien el proceso pasa a estado preparado debido a que ha agotado su
tiempo de ejecución, por lo que cede su tiempo de ejecución.
- Bloqueado (wait, en espera). El proceso está esperando a que se produzca un
evento externo, como una señal de E/S, y pasaría a estado ejecución. Al igual
que el estado preparado, el proceso puede finalizar debido a un acontecimiento
externo.
El sistema operativo utiliza varias colas para gestionar los estados, cada cola
puede tener una política diferente. Así, podemos encontrar una cola para los
estados preparados y una cola para los estados en espera. El planificador del
procesador al examinar estas colas asigna el procesador al proceso más
conveniente.

20
3.3. Planificación de un proceso
El sistema operativo es el encargado de decidir qué procesos entran en la CPU
cuando ésta queda libre, y en qué momento sale de la CPU el proceso que está en
ejecución. Todo ello se lleva a cabo a través de una política de planificación de
procesos.
Se pueden definir múltiples políticas de planificación de procesos: por orden de
llegada, primero la tarea más breve, por orden de prioridad, etc. En definitiva, lo que
una política de planificación debe conseguir es que los procesos obtengan
adecuadamente sus turnos de ejecución por lo que son tratados de la misma forma, que
no se produzca sobrecarga, es decir, el planificador debe responder rápidamente ante
cargas de trabajo ligera y responder de la misma forma ante cargas de trabajo
similares. Y obtener un buen rendimiento, por lo se debe lograr finalizar el mayor
número de procesos y maximizar el tiempo de respuesta.
No existe una política de planificación óptima para todas las computadoras, sino
que depende de las características de los procesos. Así se puede ver cómo una política
obtiene unos resultados excelentes en un sistema, sin embargo en otro sistema el
rendimiento es mucho menor. Ello se debe a las características de los procesos, donde
cada uno puede tener una cantidad de operaciones de E/S enorme cómo es el caso de
las bases de datos, otros usan mayormente la CPU, otros realizan una mayor lectura de
datos frente a otros, hay procesos que requieren una prioridad máxima en los turnos de
ejecución, es el caso de los procesos de tiempo real, y hay procesos que requieren más
tiempo de ejecución que otros, por lo que habrá que valorar si terminar primero los
cortos o no.
Existen diferentes planificadores en el sistema. Primero nos encontramos el
planificador a largo plazo, el cual es el encargado de controlar el grado de
multiprogramación en el sistema, intentando conseguir una mezcla adecuada de
trabajos en CPU y E/S. Es por tanto el encargado de suministrar los procesos a la cola
de planificación a corto plazo.
Existe también un planificador a medio plazo. Es el encargado de suspender y
posteriormente restaurar procesos de poco interés, realizando el intercambio de los
mismos entre la memoria principal y el disco o memoria secundaria. Dicho proceso es
conocido como swapping, y se ejecuta cuando hay escasez de recursos.

21
El planificador a corto a plazo es el encargado de asignar y desasignar la CPU.
Su trabajo es coger un proceso de la cola de procesos preparados y asignarle una CPU.
Hay dos tipos de planificadores a corto plazo; no expulsivas, el proceso abandona la
CPU cuando termina o a la espera de un suceso externo; y expulsivas, el proceso que
se está ejecutando puede pasar a estado listo enviado por parte del sistema operativo,
es el caso de los sistemas de tiempo compartido y tiempo real, como UNIX, Windows
NT/XP o superior, MAC OS X. Las políticas de planificación de procesos más
comunes son las siguientes:
- Primero en llegar, primero en salir (FCFS). El primero proceso que llega a la
cola de preparados será el primero en ser planificado y pasado a la CPU. Es no
expulsiva, por lo que no es adecuada para los sistemas de tiempo compartido,
por lo que provocan una especie de convoy con los procesos de E/S.
- Primero el proceso más corto (SJF). Cuando el proceso que está en la CPU cesa
su ejecución se elige de la cola de procesos preparados aquel cuya ráfaga de
CPU sea menor, es decir, que su tiempo de ejecución sea menor. Es del tipo no
expulsiva, aunque existe una versión expulsiva (SRTF) que cuando llega un
proceso más pequeño que el que se está ejecutando a la cola de preparados, éste
es bloqueado y pasa a estado preparado mientras se ejecuta el nuevo proceso.
- Prioridades. Cada proceso tiene asignada una prioridad ya sea por medio del
sistema operativo o por el usuario. Los procesos se dividen en distintas colas
dependiendo de la prioridad, por lo que el planificador elegirá primero los
procesos de la primera cola mediante FIFO, y cuando quede vacía elegirá los de
la segunda cola. Esta política puede ser expulsiva o no. Esto puede provocar que
haya procesos que se queden sin ejecutar debido a esta prioridad, la solución
pasaría por aumentar la prioridad progresivamente a los procesos en espera.
- Turno rotatorio (Round-Robin). Adecuado para los sistemas de tiempo
compartido. Consiste en generar periódicamente una interrupción de reloj, donde
cada proceso dispone de un cuanto de tiempo máximo (quantum), por lo que
cuando termina este tiempo, el proceso en ejecución pasa a preparado y pasa a
ejecutarse el siguiente proceso en la cola de preparados según FIFO.
- Retroalimentación. Otro tipo de planificación es trabajar con diferentes colas de
preparados cada una con una política diferente. Así si un proceso que ha pasado
del estado ejecución al estado preparado, primero estaba en la cola 1 y ahora

22
pasa a la cola 2, y así sucesivamente hasta llegar a la última cola hasta que
termina.
Los procesos en Linux pueden ser divididos en tres categorías: interactivos,
tiempo real o por lotes. Los procesos de tiempo real son manejados bien por un
algoritmo FIFO o turno rotatorio (Round-Robin), ya que al ser procesos considerados
como prioritarios deben de ser ejecutados antes que los demás. Los demás procesos
son manejados utilizando una planificación Round-Robin con un sistema de
envejecimiento utilizado en la planificación de prioridades mencionada
Mientras en Windows, la planificación de procesos se basa en la utilización de
colas múltiples de prioridades. Posee 23 niveles de colas clasificadas de la 31-16 en
clase de tiempo real y las demás en clase variable. Cada cola es manejada mediante
Round-Robin, pero si llega un proceso con mayor prioridad, se le es asignado el
procesador.
El caso de Mac OS X es parecido al de Windows, utilizando varias colas de
procesos cada una con un nivel de prioridad. Un hilo puede pasar de una cola a otra
dependiendo de los requerimientos. Estos niveles se pueden manejar mediante
llamadas al sistema. Los niveles son: normal, alta, Kernel y tiempo real.
3.4. Creación y destrucción de procesos
Los sistemas operativos que son objeto de estudio tienen diferentes formas en la
gestión de procesos, por lo que en este apartado haremos una distinción entre el
sistema UNIX y el sistema Windows.
El por qué se hace el estudio del sistema UNIX es debido a que tanto el sistema
Linux como el sistema Mac OS X están basados en dicho sistema, por lo que es más
razonable hacer la mención a UNIX y no a estos dos sistemas. Las únicas diferencias
fundamentales detectadas entre UNIX y Mac OS X se basan en el sistema de ficheros,
donde Mac OS X utiliza HFS+ frente al UFS de UNIX y el estándar ext3 de Linux.
Respecto al Kernel, ambos sistemas están basados en el Kernel de UNIX, pero
actualmente Mac OS X utiliza un híbrido del núcleo de UNIX Mach llamado XNU,
mientras que Linux utiliza un núcleo monolítico llamado Linux.

23
- UNIX.
Los procesos en los sistemas UNIX están identificados por un número que es
único (PID), además de que cada proceso el espacio de memoria utilizado,
formado por tres segmentos: el código, los datos y la pila. También contiene la
información de control del proceso, que indica la planificación y estado del
proceso, la estructuración de datos y la comunicación entre procesos. Otra
información importante es el número de identificación de usuario (UID) y el
número de identificación del grupo de usuarios al que pertenece el proceso
(GID). Todo ello pertenece al bloque de control de proceso (PCB).
La creación y destrucción de procesos en UNIX se ajusta a la filosofía de la
manera más sencilla posible, así las llamadas al sistema tienen el mínimo
número de parámetros. Las llamadas correspondientes a la creación, destrucción
y bloque o espera de un proceso son respectivamente: fork, exit y wait.
La llamada fork crea un nuevo proceso hijo idéntico al proceso padre. Tienen
la misma imagen de memoria, el mismo bloque de control de proceso y los
mismos archivos abiertos, aunque situados en distintos espacios de memoria.
Para poder distinguir a ambos procesos, la llamada fork devuelve distintos
valores, el hijo recibe un valor 0 y el padre el PID del hijo.
La llamada exit finaliza un proceso. Cuando se produce esta finalización del
proceso hijo, se manda al sistema la llamada wait, para que el padre se bloquee a
la espera de la finalización del hijo. Si el proceso hijo finalizara antes de que el
padre recibiera esta llamada, el proceso hijo se convertiría en un proceso en
estado zombie, y hasta que no se ejecute esta llamada wait el proceso no se
eliminará. Para evitar la acumulación de procesos UNIX prevé un límite de
números de procesos zombie y aquellos procesos hijos que se destruyen más
tarde que sus procesos padres, al quedar huérfanos sería el primer proceso del
sistema (init) el que se encarga de recoger su estado de finalización.
La llamada wait bloquea el proceso que lo ha llamado hasta que uno de sus
procesos hijos es destruido, por lo que si el proceso no tiene hijos wait regresa y
el valor devuelto es igual al Pid de dicho proceso hijo.
En UNIX se puede utilizar un comando para eliminar un proceso que se está
ejecutando por la razón que estimemos oportuno; gran consumo de recursos, ya
no es necesario, etc. Esta orden es “kill Pid proceso a eliminar”, por lo que para
eliminar un proceso primero se debe conocer su Pid.

24
- Windows.
Un programa en Windows es controlado por eventos. Así el programa
principal espera la llegada de un evento como puede ser al presionar una tecla, y
posteriormente invoca un procedimiento para procesar dicho evento,
actualización de pantalla, del programa, etc.
Windows también tiene llamadas al sistema al igual que UNIX, de hecho el
número de llamadas es extremadamente grande. En Windows encontramos que
por cada llamada al sistema existe un procedimiento de biblioteca que los
invoca. Por ello Windows ha creado un conjunto de procedimientos, llamado
API Win32 [5], que se ha de utilizar para solicitar servicios al sistema operativo.
La creación de procesos en Windows se genera mediante la llamada
CreateProcess, que tanto crea el proceso como carga el programa en el nuevo
proceso. Esta llamada tiene 10 parámetros: el programa a ejecutar, atributos de
seguridad, bits de control de archivos abiertos, prioridad, especificación de la
ventana a crear y un apuntador a la estructura a la que al invocador se le
devuelve información del proceso recién creado. CreateProcess tiene 100
funciones más para administrar y sincronizar procesos.
Al igual que en UNIX, en Windows se crea un nuevo proceso hijo a partir del
padre, el cual tiene su propio espacio de direcciones como en UNIX, pero
mientras en UNIX el espacio de direcciones del hijo era una copia del padre, en
Windows el espacio de direcciones del hijo es completamente diferente al del
padre desde el principio.
La llamada en Windows relativa a la destrucción de un proceso es
ExitProcess, y al igual que ocurría con UNIX cuando se especifica la llamada
WaitForSingleObject junto con un parámetro que especifica un proceso, quien lo
invoca espera hasta que se produce la finalización del proceso.
En Windows encontramos multitud de llamadas al sistema igual que en
UNIX (Figura 25), aunque hay algunas en UNIX que no se pueden utilizar en
Windows, como es el manejo de enlaces, manejo de montaje de unidades, etc. Si
en UNIX utilizamos la orden kill Pid para eliminar un proceso, en Windows
existe la función TerminateProcess.

25
UNIX WIN32 Descripción
Fork CreateProcess Crea un proceso nuevo
Waitpid WaitForSingleObject Puede esperar a que un proceso termine
Execve (ninguna) CreateProcess= fork + execve
Exit ExitProcess Termina la ejecución
Open CreateFile Crea un archivo o abre uno existente
Close CloseHandle Cierra un archivo
Read ReadFile Lee datos de un archivo
Write WriteFile Escribe datos en un archivo
Lseek SetFilePointer Mueve el apuntador de archivo
Stat GetFileAttributesEx Obtiene diversos atributos de archivo
Mkdir CreateDirectory Crea un directorio nuevo
Rmdir RemoveDirectory Elimina un directorio vacío
Link (ninguna) Win32 no maneja enlaces
Mount (ninguna) Win32 no maneja montajes
unmount (ninguna) Win32 no maneja montajes
Chdir SetCurrentDirectory Cambio el directorio de trabajo actual
Kill TerminateProcess Elimina un proceso
Time GetLocalTime Obtiene la hora actual
4. Gestión de memoria
La gestión de memoria se encarga de asignar la memoria física del sistema a los
programas, éstos se expanden hasta llenar la memoria con que se cuenta.
Todas las computadoras tienen una jerarquía de memoria, con una pequeña
cantidad de memoria caché, una cantidad mucho mayor de memoria principal (RAM)
y decenas o centenas de gigabyte de almacenamiento en disco.
El administrador de memoria es el encargado de administrar la jerarquía de
memoria. Es el encargado de saber qué partes de la memoria están en uso o no, asignar
y liberar la memoria principal a los procesos que la requieren, y administrar los
intercambios entre la memoria principal y el disco.
Se puede decir que los objetivos principales de un sistema de gestión de
memoria pasan por ofrecer a cada proceso un espacio lógico propio proporcionando
una protección entre los procesos, permitir que los procesos compartan la memoria.
Además se debe maximizar el rendimiento del sistema y proporcionar a los procesos
mapas de memoria grandes.
En un sistema de multiprogramación cada programa debe contener dentro del
código referencias al espacio de memoria a utilizar, ya que el mismo no siempre será
el mismo, por tanto el sistema tendrá que realizar una reubicación de las direcciones
Figura 5. Llamadas de la API Win32 que corresponden con llamadas de Unix

26
de memoria a las que hacen referencia las instrucciones de los programas para que se
correspondan con las direcciones de memoria principal asignadas al mismo. Esto se
logra a través de la unidad de manejo de memoria (MMU), que como se ha comentado
se encarga de convertir las direcciones lógicas (memoria virtual) emitidas por los
procesos en direcciones físicas. Además se encarga de que la conversión se realiza con
éxito y que el proceso que intenta acceder a las direcciones de memoria
correspondientes tiene permiso para ello.
En caso de fallo se envía una excepción que será tratada por el kernel. Éste
último está siempre en la memoria principal, ya que si estuviera en la memoria
secundaria nadie podría llevarlo a la memoria principal en caso de fallo de acceso a
memoria.
Dentro de la MMU existe una pequeña memoria asociativa denominada TLB
(Translation Lookaside Buffer), que mantiene la información de las últimas páginas
accedidas. Se puede decir que se trata de una memoria tipo caché. Con ello se evita
que el procesador esté siempre leyendo la tabla de páginas directamente, con el
consecuente decremento de rendimiento.
El funcionamiento del TLB consiste en verificar si la dirección requerida se
encuentra en el mismo, si es así automáticamente la MMU traducirá la dirección
lógica en su respectiva dirección física para ser utilizada.
En cambio, si la dirección no está presente en el TLB se produce un fallo de
página, por lo que se procederá a buscar en la tabla de dirección mediante un proceso
llamado page walk. Este proceso es costoso, ya que requiere de la lectura de múltiples
ubicaciones de memoria. Una vez determinada la dirección física a través del page
walk, el mapeo de la dirección virtual a la física es ingresado en el TLB para su
posterior uso.
4.1. Memoria principal
La memoria principal constituye el dispositivo de almacenamiento primario de
los computadores. De carácter volátil, en ella se ubican los datos que precisan los
programas para su ejecución. Esta memoria es de mayor costo que la memoria
secundaria, pero el acceso a su información es mucho mayor.

27
La memoria principal se comunica con la CPU mediante el bus de direcciones, y
es el ancho de este bus el que determina la capacidad del microporcesador para el
direccionamiento de direcciones de memoria.
Se puede decir de manera coloquial que la memoria principal está formada como
un conjunto de casillas, cada una con una dirección que las identifica, donde se
almacenan los datos y las instrucciones correspondientes a los programas. Cada casilla
está enumerada con lo que se denomina dirección de memoria.
4.2. Memoria virtual
El tamaño del programa, datos y pila puede exceder la cantidad de memoria
física disponible, por lo que el sistema guarda en la memoria secundaria aquellas
partes del programa que no están en ejecución o que no tienen espacio para ser
cargadas en la memoria principal.
La memoria virtual utiliza estos dos niveles de jerarquía de memoria: principal
y secundaria o de respaldo que suele ser el disco. Con ello podemos obtener una
cantidad de memoria mayor que la memoria física disponible, y por tanto ejecutar
procesos con una memoria lógica mayor que la memoria física disponible.
Hay que resaltar que el uso de la memoria virtual no acelera la ejecución de un
programa, sino que puede incluso que la ralentice debido a la sobrecarga asociada a las
transferencias entre la memoria principal y la secundaria. Esto hace que esta técnica no
sea apropiada para sistemas de tiempo real.
Sobre la memoria de respaldo se establece un mapa uniforme de memoria
virtual, y son a estas direcciones del mapa a las que se refiere el procesador en la
ejecución del programa, pero los accesos reales se realizan sobre la memoria principal.
La memoria virtual requiere por tanto de una gestión automática de la jerarquía de
memoria formada por la memoria principal y el disco.
El sistema operativo gestiona la transferencia de bloques desde la memoria
principal a la memoria secundaria que sirve de respaldo a la memoria virtual. Las
direcciones generadas por las instrucciones máquina están referidas al espacio virtual.
En este sentido se habla de que el procesador genera direcciones virtuales.
El mapa virtual asociado a un programa en ejecución está soportado
físicamente por una zona del disco denominada de intercambio o swap, y por una zona
de la memoria principal.

28
La memoria virtual se implementa sobre un esquema de paginación. A este
dispositivo se le denomina dispositivo de paginación. Se denominan páginas virtuales
a las páginas de espacio virtual, páginas de intercambio a las páginas residentes en el
disco y marcos de página a los espacios en los que se divide la memoria principal.
Cada marco de página es capaz de albergar una página virtual cualquiera. Se
puede decir que la unidad de hardware denominada MMU, traduce el número de
página virtual en el correspondiente número de marco de página.
Cuando las páginas de memoria de un programa necesarias para su ejecución
no se encuentren en memoria principal, la MMU producirá la respectiva excepción.
Los fallos de página son atendidos por el sistema operativo que se encarga de
realizar la adecuada migración de páginas, para traer la página requerida por el
programa a un marco de página. Se denomina paginación por demanda al proceso de
migración necesario para atender los fallos de página. En el siguiente punto se
profundizará más en este proceso de paginación.
También cabe reseñar que el tamaño del espacio virtual suele ser muy grande,
y dado que los programas requieren en general mucho menos espacio, una de las
funciones que realizar el sistema operativo es la asignación de espacio virtual a los
programas en ejecución. El programa no podrá utilizar todo el espacio virtual sino que
se tiene que restringir a la zona o zonas que le asigne el sistema operativo. Estas zonas
se denominan segmentos, y a dicho proceso segmentación que se profundizará más
adelante.
4.2.1. Traducción de página virtual a física
La memoria física de un ordenador es una secuencia de bytes donde cada
bytes tiene una dirección que es la posición que ocupa en la propia memoria.
Las direcciones de memoria que utiliza un programa no son directamente
las direcciones físicas, sino que son direcciones lógicas que son traducidas o
mapeadas en direcciones físicas.
Para realizar la traducción es necesaria la utilización de hardware con
ayuda del sistema operativo. Respecto a este hardware hablamos del gestor de
memoria (MMU) junto con el búfer de traducción anticipada de instrucciones
(TLB).

29
El gestor de memoria será el encargado de traducir las direcciones
virtuales a direcciones de memoria principal, de tal forma que cada una
corresponda con su respectivo marco de página.
4.2.2. Paginación
La paginación surge como intento de paliar los problemas de asignación de
memoria contigua, sofisticando el hardware de gestión de memoria (MMU) del
procesador y aumentando considerablemente la cantidad de información de
traducción que se almacena por cada proceso.
La MMU usa dos tablas de páginas. Una tabla de páginas de usuario para
traducir las direcciones lógicas del espacio de usuario y una tabla de páginas
del sistema para las direcciones lógicas del espacio del sistema.
La paginación no proporciona un aprovechamiento óptimo de la memoria
como lo haría un esquema que permitiese que cada palabra del mapa de
memoria de un proceso pudiera corresponder con cualquier dirección de
memoria, pero esto implicaría una enorme cantidad de información de
traducción. En la paginación cada página del mapa de un proceso puede
corresponder con cualquier marco de memoria. Esto reduce drásticamente el
tamaño de la tabla de traducción.
Cada entrada de la tabla de páginas, además del número de marco que
corresponde con esa página, contiene información adicional como la protección
de la información y la indicación de página válida mediante un bit de
confirmación.
Un aspecto importante en el rendimiento de un sistema de paginación es el
tamaño de la página. Un tamaño pequeño reduce la fragmentación y permite
ajustarse mejor al conjunto de trabajo del proceso. Sin embargo, un tamaño
grande implica tablas más pequeñas y un mejor rendimiento en los accesos a
disco.
4.2.3. Segmentación
El sistema operativo debe guardar para cada proceso una tabla de regiones
que especifiquen qué páginas pertenecen a cada región. Esto implica que hay
que rellenar las entradas de las páginas pertenecientes a la región con las

30
mismas características y que para compartir la región, las entradas
correspondientes de dos procesos deben apuntar al mismo marco.
La segmentación es una técnica que intenta dar soporte a las regiones. Para
ello, considera el mapa de memoria de un proceso compuesto de múltiples
segmentos. Cada región se almacenará en un segmento que tendrá un tamaño
variable.
Dado que cada segmento se almacena en memoria de forma contigua, este
esquema presenta fragmentación externa, por lo que hace disminuir el
rendimiento de dicho sistema.
4.3. Gestión de Memoria en UNIX
Al igual que en el apartado de procesos se realizó una comparación de la forma
en que los dos sistemas operativos; UNIX y Windows, realizan dicha tarea, en este
punto se realizará unas reseñas de cómo el sistema UNIX realiza la gestión de
memoria, y en el punto 4.4 se realizará sobre el sistema Windows.
Sólo se realizará este estudio de estos dos sistemas, porque cómo ya se ha
comentado, los sistemas que van a ser objeto de estudio, Linux y Mac OS X, están
diseñados a partir de UNIX, de ahí que se elija dicho sistema. El otro sistema a
estudiar será Windows 7, de ahí que sea también objeto de estudio.
En el sistema operativo UNIX, la gestión de memoria ha variado de las
versiones antiguas a las actuales. Antes, UNIX se basaba sólo en el intercambio
(swapping) donde se empleaban particiones variables sin ningún tipo de esquema de
memoria virtual. Las versiones actuales se basan en la memoria virtual paginada,
utilizando para ello la paginación combinado con el intercambio.
Las direcciones lógicas generadas por un programa se dividen en un número de
páginas con el mismo tamaño. Este tamaño varía dependiendo de la versión,
utilizándose en versiones anteriores tamaños de 512 bits o 1024 bits. Hoy en día, con
las CPUs actuales el tamaño de página en los equipos a 32 bits es de 4 KB, por lo que
el espacio de direcciones es de 2 elevado a 32 bits (4 GB).
Respecto a la paginación, ya se ha tratado en el punto 4.2.1., UNIX utiliza las
tablas de páginas, el descriptor del bloque donde se almacena la información para
acceder a la página en memoria secundaria y los marcos de página que guarda

31
información acerca del estado de la página, el número de procesos que referencia al
marco y el dispositivo que contiene la copia de la página.
Los marcos no asignables a un proceso son marcos libres asignables a cualquier
proceso. El sistema define el número mínimo de marcos libres, que comprueba
periódicamente. Si en un instante no se alcanza dicho límite, un proceso paginador
envejece las páginas. Toda referencia a una página pone a cero la edad de la página. Si
la página pasa una edad, la página pasa a estado libre. La página de un marco libre
puede ser rescatada en una referencia si el marco no hubiera sido asignado antes.
En situaciones donde hay mucha demanda por parte de los procesos, puede
ocurrir que el paginador no sea capaz de conseguir marcos libres a la velocidad
necesaria. Entonces es cuando se produce el swapping, mediante el cual se saca algún
proceso de la memoria principal y se pasa a la memoria secundaria (swap out). En
cambio cuando existe espacio en la memoria principal, se intercambian los procesos a
memoria copiando desde el área de intercambio (swap in). Los criterios de elección se
basan en el estado del proceso, su prioridad, el tamaño del programa y el tiempo que
lleva en memoria.
Para soportar swapping se requiere un espacio de intercambio en
almacenamiento secundario, normalmente en un disco. Se puede utilizar un dispositivo
específico, una partición del disco o incluso compartir la misma partición del sistema
de ficheros. En los sistemas UNIX se suele utilizar una partición del disco para ello.
En los sistemas UNIX se puede observar como en memoria se carga todo lo que
se pueda. Es decir, se utiliza la memoria como caché de datos. Esto se utiliza para
optimizar el sistema y hacerlo más rápido. En memoria se carga todos los datos a los
que tenga que acceder la CPU, por lo que si ésta tiene los datos en memoria en vez de
en el disco, la rapidez de acceso a los mismos será mayor, por lo que el rendimiento
aumenta. Ello hace que se optimice la mayor cantidad de memoria principal
disponible, ya que el uso de la misma es del 100%. En cuanto, un proceso requiera de
memoria se utilizará los mecanismos de swapping ya descritos liberando la memoria
utilizada para caché. Ello no ocurre en el sistema Windows donde como se verá en el
siguiente punto no utiliza el total de la memoria para caché de datos de la CPU.
En UNIX las páginas pueden estar en diferentes estados. El valor de este estado
se refleja en el campo flags de la página. A continuación se describen los estados que
puede estar una página:

32
CONSTANTE
(FLAGS)
VALOR SIGNIFICADO
PG_locked 0 La página está bloqueada en memoria
PG_error 1 Se ha producido un error en la carga de la página en
memoria
PG_referenced 2 La página ha sido accedida
PG_uptodate 3 El contenido de la página está actualizado
PG_dirty 4 Indica si el contenido de la página se ha modificado
PG_lru 5 La página está en la lista de páginas activas e inactivas
PG_active 6 La página está en la lista de páginas activas
PG_slab 7 El marco de página está incluido en un slab
PG_owner_priv_1 8
PG_arch_1 9
PG_reserved 10 La página está reservada para un uso futuro, no es
posible acceder a ella.
PG_private 11 Contiene datos privados
PG_writeback 12 Se indica que la pagina usa el método writeback
PG_compound 14
PG_swapcache 15 Indica si la página esta intercambiada
PG_mappedtodisk 16 Indica si la página está intercambiada
PG_reclaim 17 Página marcada para escribirse a disco
PG_buddy 19 Página libre en listas buddy
4.4. Gestión de Memoria en Windows
Los procesos dentro de Windows utilizan un espacio de direcciones de 32 bits
que permite habilitar un espacio de direcciones de hasta 4 gigabytes de direcciones, o
8 terabytes en el caso de los sistemas de 64 bits.
Cuando todos los procesos que se ejecutan en el sistema requieren de más
memoria que la disponible, Windows utiliza la alternancia entre la memoria virtual
(determinado por un archivo de paginación) y la memoria física, que al igual que en
UNIX recibe el nombre de swapping.
Este intercambio se realiza no de bytes a bytes, sino de página a página, que en
Windows son bloques de 4 KB donde se almacenan los datos de los procesos. De ahí
que toda la memoria esté paginada, tanto la física como la virtual. La física en forma
de marcos de página y la virtual en forma de páginas.
Además, Windows dispone de tablas de páginas que son las que apuntan a las
propias páginas, y los punteros de estas tablas se almacenan a su vez en un directorio
de páginas. Cada proceso dispone sólo de un directorio.
Figura 6. Estados de las páginas de memoria en UNIX

33
El espacio de direcciones para un proceso es el conjunto de direcciones de
memoria virtual que puede utilizar. El espacio de direcciones para cada proceso es
privado y no se puede acceder por otros procedimientos, a menos que se comparta.
Una dirección virtual no representa la ubicación física real de un objeto en la
memoria, sino que el sistema mantiene una tabla de páginas para cada proceso. El
sistema traduce la dirección virtual a una dirección física mediante diferentes
algoritmos, lo que hace que no se pueda acceder a las posiciones de otros procesos
porque no es posible hacer referencia a dichas posiciones.
A diferencia de los otros sistemas, las páginas pueden estar en tres estados; libre,
donde no puede ser accedida por ningún proceso pero sí reservada o encargada;
reservada, es un espacio de dirección virtual fijada para usos futuros; encargada,
aquella que ha sido asignada a un espacio físico, ya sea en memoria física o virtual.
5. Implementación
A lo largo de los siguientes apartados se realizará una descripción de los pasos
seguidos en la instalación y configuración de los equipos para realizar los respectivos
test.
De esta forma, tendremos una idea de los pasos necesarios para poder abordar el
problema del análisis de los distintos sistemas. Se detallarán los problemas
encontrados en la instalación de dichos sistemas, de su posterior instalación dentro de
un Hypervisor y de la instalación y configuración de Apache como servidor Web.
Además se hará una breve explicación de los puntos relativos a los programas de
benchmarking utilizados, es decir, cómo se realizarán los test, qué configuración de
dichos programas será necesaria para dicha acción, etc.
En definitiva, se mencionarán todos los pasos necesarios para implantar el
pequeño laboratorio de test.
5.1. Hypervisor
5.1.1. Concepto de Hypervisor
La virtualización es una tecnología compuesta por una capa de software
permitiendo la instalación y utilización de varios sistemas operativos sobre la
misma máquina física. Esta capa de software es el Hypervisor o Monitor de
Máquina Virtual (Virtual Machine Monitor, VMM).

34
El VMM crea una capa de abstracción entre el hardware de la
computadora central, o física (host), y el sistema o sistemas operativos de las
máquinas virtuales. De manera que presenta un hardware compatible con los
sistemas operativos que se vayan a instalar. La máquina virtual es un sistema
operativo que corre como si estuviera instalado en una plataforma de hardware
autónoma.
La VMM maneja y gestiona los cuatro recursos principales de la
computadora: CPU, Memoria, Almacenamiento y Red. La VMM puede
distribuir dinámicamente dichos recursos entre las distintas máquinas virtuales.
Hay varios tipos de virtualización como ya se ha comentado.
- Tipo I. Denominada virtualización nativa o bare metal (metal desnudo).
Consiste en la instalación del software Hypervisor sobre el hardware de
la máquina física.
- Tipo II. Denominada hosted, donde el software Hypervisor se instala
sobre el sistema operativo que contenga el host.
5.1.2. Instalación del Hypervisor
Como se ha comentado en la introducción de este trabajo, en concreto en
el punto 1.3 Planificación del proyecto, el software de virtualización que
vamos a utilizar es VMWare WorkStation 7.
En un principio la opción elegida era VMWare Server 2, debido a que este
tipo de virtualización era del tipo I, y se podrían ver mejores resultados. Pero
debido a la incompatibilidad del hardware de la máquina que se está utilizando
no ha sido posible instalar dicho software.
La instalación de VMWare WorkStation 7 se ha realizado sobre el sistema
operativo Windows 7 Profesional 64 bits. La instalación ha sido estándar por lo
que no ha requerido de ninguna configuración especial.
5.1.3. Creación y configuración de máquinas virtuales
Para la creación de las máquinas virtuales se han utilizados los mismos
parámetros para cada uno de los tres sistemas a instalar. Para que cada uno
tenga el mismo hardware.
Dicho hardware se compone de los siguientes parámetros:

35
- La primera opción que aparece es la especificación del número de
procesadores. Se ha elegido utilizar un procesador con 2 cores por
procesador, por lo que en total tendrá dos procesadores. Como ilustra la
siguiente imagen.
- Memoria. El tamaño de la memoria será el mismo para todos. En este
caso se va a proporcionar 2 GB de memoria RAM a cada equipo.
Aunque el equipo físico sólo dispone de 4 GB, se tendrá que iniciar cada
equipo de forma individual para proceder a su análisis. Nunca tendremos
iniciados los tres equipos a la vez. A continuación se muestra la imagen
con la opción de memoria elegida (Figura 8).
Figura 8. Tamaño de memoria elegida para las máquinas virtuales
Figura 7. Número de procesadores

36
- La siguiente opción a elegir en la creación de la máquina virtual es la
conexión de red. En este caso la opción ha de ser “Use bridged
networking” (Figura 9). De este modo cada máquina podrá tener su
propia dirección ip.
- Seleccionamos el controlador SCSI por defecto por ser más compatibles
que otros. Al utilizar distintos sistemas operativos tan dispares, si se
quiere tener las máquinas lo más parecida posible se tiene que optar por
los componentes estándar en detrimento de componentes que puedan dar
mayor rendimiento.
Figura 9. Modo de conexión de red
Figura 10. Modo de conexión de red

37
- Otra de las opciones a configurar será la capacidad del disco que será de
20 GB. Además se configura que dicho sistema sea guardado en un
fichero lo que permite mayor seguridad a la hora de hacer copias de
seguridad.
Se puede ver en la siguiente imagen (Figura 12) las tres máquinas virtuales
creadas, y como está ejecutándose la máquina virtual con el sistema operativo
Mac OS X 10.6.4
Figura 11. Capacidad del disco
Figura 12. Máquinas Virtuales en VMware

38
5.1.4. Instalación de los Sistemas Operativos
La instalación de los sistemas operativos se lleva a cabo igual que en una
computadora normal. En este caso VMWare permite elegir como origen de la
instalación una imagen iso del sistema operativo, por lo que no sería necesario
tener acumulados los CD o DVD de instalación de dichos sistemas.
Respecto a la instalación de los sistemas operativos, se realizará una
instalación estándar en cada uno de ellos, configurando sólo los aspectos de
zona horaria, usuario y demás campos estándar solicitados.
No se instalará ningún software que no sea los necesarios para la
instalación de Wordpress, que será la aplicación web que proporcionará las
páginas que serán testeadas por los benchmarking. Dicho requerimiento consta
del servidor web Apache, del entorno de programación PHP y del gestor de
base de datos Mysql.
A continuación se muestra una imagen con el comienzo de la instalación
de uno de los sistemas operativos. En concreto se trata de la instalación del
sistema operativo Ubuntu, el cual se ha instalado desde una imagen iso
descargada desde la página oficial de dicho sistema [6].
Figura 13. Instalación de Ubuntu en máquina virtual

39
Dentro de los problemas encontrados en la instalación de los sistemas,
cabe mencionar la utilización de la EFI (Extensible Firmware Interface) a la
hora de instalar Mac OS X. Esta interface es necesaria para el arranque del
sistema Mac OS X y hace las funciones de la BIOS de las computadoras
personales (PC).
No se han encontrado ningún tipo de problema de otra índole, como por
ejemplo en la creación de particiones. Al dejar todo por defecto no se ha
encontrado ninguna diferencia entre dichos sistemas operativos.
5.2. Sistemas Operativos
5.2.1. Configuración
La configuración de los sistemas operativos se va a basar simplemente en
la configuración de una ip diferente en cada uno de los sistemas, para
diferenciar claramente el acceso a cada uno de ellos. De esta manera los
sistemas tendrán las siguientes direcciones de red.
Respecto a la configuración que haya que realizar para poder instalar las
aplicaciones Apache, PHP y Mysql, se realizarán en el punto 5.2.2 y sus
apartados.
- Sistema Ubuntu. Tendrá como dirección de red la siguiente:
Dirección IP 192.168.1.210
Máscara de subred 255.255.255.0
Puerta de enlace 192.168.1.100
Servidores DNS
192.168.1.13
192.168.1.11
- Sistema Windows. Tendrá la siguiente dirección de red:
Servidores DNS
192.168.1.13
192.168.1.11

40
- Sistema Mac OS X. tendrá como dirección de red:
Servidores DNS
192.168.1.13
192.168.1.11
5.2.2. Servidor Web Apache
5.2.2.1. Concepto
Apache es un software código abierto que pone a disposición de todo
aquel que quiera utilizarlo como servidor web. Este software es fruto de la
colaboración de un grupo de voluntarios en todo el mundo que planean y
desarrollan las mejoras necesarias para conseguir una implementación de
código robusto.
Apache es un servidor modular, por lo que se irán añadiendo aquellos
módulos que sean necesarios. También es multiplataforma, ya que se puede
instalar en sistemas tan diversos como UNIX, Windows, Mac, etc. como se
podrá comprobar a lo largo de este trabajo.
Apache presenta entre otras características mensajes de error altamente
configurables, bases de datos de autenticación, etc. pero la falta de una
interfaz gráfica que ayude a su configuración hace que reciba ciertas
críticas. A pesar de todo es el servidor HTTP más utilizado en los sitios web
de todo el mundo con un 66.62 % [33].
5.2.2.2. Instalación y configuración
Dependiendo del sistema operativo la instalación será de manera
diferente. Por lo que veremos cada sistema por separado.
También se comentarán los pasos a seguir para la instalación de las
herramientas del entorno PHP y el gestor de bases de datos Mysql para cada
uno de los sistemas.
Respecto a la configuración de apache en los distintos sistemas será muy
similar en el comienzo, ya que todas las instalaciones se hacen por defecto y
suelen tener la misma configuración. Sólo cabe mencionar que se realizará
el cambio de ubicación del DocumentRoot o directorio principal donde

41
residirán las páginas web que servirá el servidor. También habrá que indicar
a Apache que utilice como página índice index.php. Y por último se
añadirán aquellas líneas necesarias para que apache sepa que el entorno PHP
está disponible.
A continuación se realizará una descripción de los pasos realizados para
la instalación y puesta en marcha de apache.
- Ubuntu.
Para la instalación de las aplicaciones se ha utilizado el gestor de
paquetes Synaptics. Mediante dicho gestor se han ido buscando los
módulos necesarios. En concreto se ha buscado apache2, php5 y Mysql.
A la hora de instalar estos paquetes, el propio gestor informa de los
módulos que también serán instalados por ser necesarios.
Otra forma de instalar estas aplicaciones habría sido a través de un
terminal, y con la orden “aptitude install paquete”, donde paquete sería
en nombre del paquete a instalar, o mediante la orden “apt-get install
paquete”.
No existe diferencia entre uno u otra a la hora de realizar la instalación
del software que queramos. La diferencia la encontramos en el modo de
gestionar los paquetes, ya sea buscándolos, borrándolos, actualizándolos,
etc. Mientras apt tiene diferentes herramientas con sus respectivos
argumentos para realizar dichas tareas, mientras aptitude sólo utiliza una
herramienta, el propio aptitude, con diferentes argumentos para realizar
las mismas tareas que apt. También cabe mencionar que aptitude ha
manejado siempre mejor la eliminación de paquetes junto con sus
dependencias huérfanas. Algo que apt ha mejorado en las versiones
recientes con “apt-get autoremove”.
Respecto a los cambios de configuración en las distintas aplicaciones,
no se ha realizado ninguno al respecto. Se ha dejado la configuración tal
cual, ya que para que funcione la aplicación Wordpress no es necesario
realizar ningún cambio.
En la siguiente imagen se puede ver que se ha logrado correctamente
la instalación de Wordpress en Ubuntu para su posterior testeo.

42
- Windows 7.
En la instalación de los programas en Windows, se ha realizado la
instalación de cada uno de ellos por separado, realizando primero la
descarga de los mismos desde sus páginas oficiales.
Una vez han sido instalados, hay que realizar unos cambios en la
configuración de Apache para que el mismo tenga conocimiento de que
el entorno de PHP está disponible. Para ello hay que cargar el módulo de
PHP. “LoadModule php5_module C:/Servidor/PHP/php5apache2.dll”, y
posteriormente se añaden unas líneas de código necesarias para que Apache
pueda interpretar las extensiones de PHP.
Se puede observar como se ha logrado la correcta instalación de
Wordpress en dicho sistema operativo.
Figura 14. Instalación correcta de Wordpress en Ubuntu.

43
- Mac OS X.
En este sistema operativo ha sido muy sencilla la puesta en marcha del
servidor web Apache junto con PHP, y la instalación de Mysql.
Este sistema ya viene con la instalación de Apache y PHP en el
mismo, así lo único que hay que realizar es la activación de ambas
herramientas. En el caso de Apache se encuentra dentro de las
herramientas de sistema>sharing>Web Sharing. En el caso de PHP sólo
hay que asegurarse que Apache conozca que PHP está instalado. Para
ello se añaden varias líneas de código dentro del fichero de configuración
de Apache (httpd.conf), y con ello ya tenemos php funcionando. Estas
líneas son:
· AddType application/x-httpd-php .php
· AddType application/x-httpd-php-source .php5
En el caso de Mysql lo único que tenemos que hacer es descargarnos
el paquete .dmg desde la web de Mysql [27]. Una vez descargado la
instalamos y simplemente tenemos que iniciar el servicio de Mysql.
Una vez creada la base de datos para Wordpress, ya podemos realizar
la instalación de éste para su posterior utilización (Figura 16).
Figura 15. Instalación correcta de Wordpress en Windows.

44
5.3. Benchmarking
5.3.1. Descripción y tipos
El benchmarking es una forma de determinar qué tan bien funciona un
producto o empresa respecto a otras. El benchmarking utiliza la evaluación
continua y sistemática de los productos, servicios, procesos, etc. para obtener
una representación de entre los analizados de cuáles forman una referencia o
modelo a seguir.
Este proceso de benchmarking es utilizado por las empresas para ver su
competitividad respecto a otras del mismo sector. En nuestro caso lo
utilizaremos para ver la competitividad de los tres sistemas operativos respecto
a un mismo problema como es el de servir páginas web mediante el servidor
web Apache.
Las herramientas a utilizar son las ya mencionadas; JMeter [25] y ab [26].
Ambas herramientas están creadas para testear el rendimiento de Apache, sobre
todo ab, la cual está integrada dentro de la instalación del propio Apache, por
lo que no es necesaria su instalación, de ahí que sólo es posible utilizarla desde
la propia máquina donde está instalado el servidor Apache. En cambio JMeter,
Figura 16. Instalación correcta de Wordpress en Mac OS X.

45
aunque en un principio fue diseñada para testear aplicaciones web, actualmente
puede testear otras funciones como bases de datos, servidores de correo,
servidores LDPA, etc. JMeter a diferencia de ab, sí puede ser ejecutada desde
un equipo distinto al que tiene instalado la aplicación web, pero evidentemente
tienen que estar en la misma red, o el equipo a testear ser visible desde JMeter.
5.3.2. Instalación y configuración
Cómo ya se ha comentado la aplicación ab no requiere de ninguna
instalación, ya que forma parte de Apache. Respecto a los parámetros que se
utilizarán serán como los siguientes: “ab –c 100 –n 20 http://localhost/”
Con estos parámetros le indicamos a la aplicación que realice un test de
100 solicitudes (-c 100) con 20 peticiones concurrentes (-n 20) al servidor
localhost. En cada uno de los test se especificará el número de peticiones y
solicitudes concurrentes.
Respecto a los datos que se van a obtener con este benchmark, nos
centraremos principalmente en los valores “Request per second” (páginas
servidas por segundo) y “Time per Request” (tiempo por respuesta). Con ello
se podrá realizar un seguimiento de cómo cada uno de los sistemas es capaz de
ejecutar más procesos y poder servir cuanto antes las páginas solicitadas.
En la siguiente imagen (Figura 17) tenemos un ejemplo de una captura de
un test realizado con ab, en el cual se puede apreciar cómo se han completado
500 peticiones con 50 usuarios concurrentes. En dicho test se ha obtenido una
media de 3,79 páginas por segundo, con un tiempo medio de 13 segundos por
petición.

46
En cuanto a JMeter, no requiere una instalación como tal, ya que se trata
de una aplicación diseñada en Java 100%, por lo que puede ser ejecutada en
cualquier plataforma que tenga instalada la máquina virtual java 1.5 o superior.
Una vez descargada lo único que tenemos hacer es ejecutar el archivo
bin>jmeter.bat (en el caso de Windows) y se mostrará la ventana de la
aplicación. A partir de ahí habrá que realizar los distintos cambios y
configuraciones que creamos oportunos para realizar el test.
Sin querer hacer un tutorial de JMeter, se realizará una breve explicación
de los pasos a seguir en la configuración del mismo para llevar a cabo el test.
Con JMeter podemos hacer que grabe todas las peticiones que hagamos
desde un navegador web hacia el servidor web, por lo que nos ahorramos la
comunicación entre el cliente web y la aplicación. Para llevar a cabo dicho
trabajo tendremos que realizar una serie de configuraciones tanto en la
herramienta JMeter como en el navegador donde reside dicha herramienta.
Figura 17. Captura test apache

47
Respecto a la secuencia que JMeter va a grabar y llevará a cabo contra la
aplicación web, será siempre la misma respecto a los distintos sistemas
operativos. Esta secuencia será la siguiente:
- Acceder a la página principal de Wordpress en dicho servidor
- Ingresar con usuario y contraseña a la aplicación web
- Crear una nueva entrada dentro Wordpress
- Publicar dicha entrada
- Ver la entrada nueva
- Salir de Wordpress
Esta secuencia se puede ver en la Figura 20
Una vez que ya sabemos la secuencia que se va a realizar, pasamos a
describir la configuración necesaria en JMeter para que lleve a cabo la
grabación de esta secuencia. Para ello cuando iniciamos JMeter se nos presenta
una interfaz con dos partes (figura 18); en la izquierda aparecerá el Plan de
Pruebas junto con el Banco de Trabajo, y en la parte de la derecha todas las
configuraciones posibles de los anteriores dependiendo de cuál elegimos.
Lo primero que haremos será crear un nuevo Grupo de Hilos dentro del
Plan de Pruebas, para ello nos situamos sobre el mismo, y en la opción
Editar>Añadir>Threads(Users)>Grupo de Hilos. Una vez creado podemos
cambiar dicho nombre y configurar las propiedades, que como se puede ver
comprende los siguientes parámetros (Figura 19):
Figura 18. Interfaz de JMeter

48
- Número de hilos. Es el número de usuarios que JMeter va a simular. En
nuestro caso utilizaremos el valor 10 y 40, por lo que simulará 10 o 40
usuarios accediendo a la web y realizando las mismas acciones ya
descritas.
- Periodo de subida. Es el tiempo en segundos que se quiere que
transcurra entre cada grupo de hilos. Utilizaremos el valor 10.
- Contador del bucle. Es el número de ciclos que se van a repetir. En este
caso realizaremos 1 ciclo. Tenemos la opción de “Sin fin”, que realizaría
el test indefinidamente.
Si ya tenemos creado el Grupo de Hilos, procedemos a crear dentro del
Banco de Pruebas un elemento NoDePrueba, concretamente “Servidor Proxy
HTTP”. Con ello estamos configurando JMeter como servidor Proxy, así lo
único que tenemos que hacer es indicarle al navegador web que utilice un
servidor proxy en sus conexiones y le indicamos el puerto configurado en el
mismo que por defecto será el 8080. Una vez configurado el servidor proxy
pulsamos en el botón Arrancar, y ya tenemos funcionando el servidor proxy. A
partir de este momento y una vez configurado el navegador web
correspondiente, todas las páginas consultadas por dicho navegador quedarán
grabadas en el plan de trabajo (Figura 20).
Figura 19. Parámetros del Grupo de Hilos

49
Con JMeter se puede seleccionar una serie de herramientas que analizan y
evalúan el test realizado, obteniendo de esta manera gráficas o tablas de
resultado que ayudan a la hora de estudiar el rendimiento del sistema.
Hay diferentes “Listener”, como se denomina en JMeter, con los que
obtener los datos del rendimiento del equipo a evaluar. Algunos de ellos son
válidos para conocer el rendimiento de la CPU de un equipo u otras medidas
que no serán llevadas a cabo en este trabajo. Las dos herramientas o monitores
que se utilizarán son: “Graph Results” (Gráfico de resultados – Figura 21) y
“Summary Report” (informe de síntesis – Figura 22). En el primero se obtiene
varios gráficos con la evolución de la prueba. Estos gráficos indican
Figura 20. Captura de la secuencia de las páginas visitadas

50
parámetros como el número real de peticiones por minuto que el servidor
maneja realmente, lo que nos permite probar con parámetros que aumenten el
número de usuarios concurrentes y/o disminuyan los retrasos hasta alcanzar el
mayor rendimiento.
Respecto al informe, se obtiene una tabla con los datos referidos a cada
una de las muestras (cada uno de los hilos que forman el test). De cada una de
ellas se puede observar el número de veces que se accede a esa muestra, el
tiempo medio transcurrido, el rendimiento referido a las páginas por segundo
que el servidor ha servido, etc. Además se obtienen los totales de dichos
parámetros, así tendremos una idea clara del rendimiento actual del servidor.
Figura 21. Gráfico de resultado de JMeter
Figura 22. Tabla del informe de síntesis de JMeter

51
6. Evaluación de los Sistemas Operativos
Tras la instalación y configuración de los sistemas operativos, así como de la
herramienta Apache y demás software necesario para hacer funcionar Wordpress
(como php y mysql), se ha llevado a cabo una serie de pruebas de estrés a cada uno de
los sistemas para comprobar su rendimiento.
Para la realización de las pruebas se han utilizado las herramientas de
benchmarking ya mencionadas (ab y JMeter). Los resultados de las mismas serán
expuestos en los siguientes apartados, realizando un análisis de aquellos aspectos que
se consideren más relevantes. Cabe decir que el resultado que se obtenga y sea
plasmado en sus respectivas tablas, será la media resultante de la realización de 5
pruebas del mismo tipo y con el mismo software, es decir, en cada una de las pruebas
realizadas se ejecutarán 5 pruebas iguales, y la media de las mismas será el resultado
que se plasmará en los siguientes apartados.
Las pruebas a realizar en el test inicial consistirán en dos partes. Por un lado
realizaremos una prueba con la herramienta ab a la página principal de Wordpress, en
concreto a la página index.php. De esta forma se podrá ver el cambio que se produce
en cuanto a servir la página de forma dinámica, o servir dicha página estáticamente
debido a la caché en disco.
Por otro lado, con la herramienta JMeter se podrá realizar un test más completo,
ya que se seguirá la secuencia descrita en el apartado 5.3.2. (Figura 20). Como se
aprecia en dicha secuencia, se va a proceder a testear tanto páginas estáticas
(fundamentalmente .css, .js) como páginas dinámicas. En este caso, hay algunas
páginas dinámicas que no pueden ser cacheadas, por lo que el resultado obtenido será
bastante realista en cuanto al rendimiento aportado una vez realizado los cambios de
configuración en Apache.
Respecto a los cambios a realizar, se realizarán primero los cambios pertinentes
en el servidor web Apache, y una vez obtenido dichos resultados, se realizarán
también cambios en la configuración de memoria física y procesador para constatar el
rendimiento que los mismos producen en los sistemas.

52
6.1. Test inicial
Con estos test se podrá tener una primera aproximación del rendimiento
que ofrecen los sistemas operativos en su tarea de servir páginas web.
Se han llevado a cabo dos test con diferentes valores. En el primero se ha
utilizado 10 usuarios concurrentes realizando cada uno de ellos una petición de
100 páginas.
Mientras que en el segundo test se ha realizado una muestra con 50
usuarios concurrentes realizando 500 peticiones. De esta forma se intenta llevar
al servidor más al límite.
Tras examinar los resultados de los diferentes test realizados, se ha creado
la siguiente tabla (Figura 23) y una gráfica en la que se puede apreciar mejor
las diferencias entre cada uno de los sistemas. Como se observa en dicha tabla,
el sistema que obtiene mejores resultados es Ubuntu, tanto en el número de
páginas que el servidor puede servir por segundo, cómo por la utilización de la
memoria física. Esto indica que no por utilizar más memoria, necesariamente
se obtiene mayor rendimiento, sino que hay que buscar la configuración y
herramientas idóneas para realizar una tarea con el mejor rendimiento.
Los datos referidos en la tabla corresponden a:
- Uso de memoria. Es el uso de memoria Física en el momento en el que
se realiza el test.
- Rendimiento (muestras/segundos). Es el número medio de páginas que
se han servido a lo largo del test.
- Tiempo de respuesta por petición (segundos). Es el tiempo en segundos
de la duración en que el servidor tarda en servir una petición.
- Tiempo de respuesta media de conjunto (segundos). Es el tiempo medio
en segundos que ha tardado el servidor en servir todas las páginas
solicitadas desde JMeter, donde no sólo se realiza la petición de una
página sino de varias.

53
Test con 10 usuarios y 100 muestras
Uso de
Memoria
(%)
Rendimiento
(muestras/segu
ndos)
Tiempo de respuesta
por petición
(segundos)
Ubuntu 35 7,13 0,139
Windows 7 75 3,15 0,364
Mac OS X 50 4,02 0,263
Se ha realizado un segundo test inicial para observar el comportamiento de
los sistemas ante una mayor carga de trabajo. En concreto, se ha configurado
los benchmark con 50 conexiones concurrentes cada una de las cuales realiza
500 solicitudes al servidor. Los datos obtenidos se recogen en la siguiente tabla
y gráfico (Figura 24).
En esta tabla se recoge el tiempo medio de respuesta de todo el conjunto
de páginas analizadas mediante JMeter. Este tiempo nos servirá para
compararlo con el test final.
En los datos recogidos se puede apreciar cómo tanto el sistema Ubuntu
como el sistema Mac OS X realizan un mayor uso de memoria frente al test
anterior, y cómo disminuye en todos los casos el rendimiento. En cualquier
caso, sigue siendo Ubuntu el sistema con mejor rendimiento.
En este sentido encontramos un caso curioso, y es que Ubuntu obtiene un
mayor rendimiento respecto a Mac OS X, siendo ambos sistemas
prácticamente iguales en cuanto a que los dos se basan en la arquitectura de
0
1
2
3
4
5
6
7
8
9
10
uso de Memoria (%) Rendimiento
(muestras/sec)
Tiempo por
respuesta (sec)
Ubuntu
Windows 7
Mac OS X
Figura 23. Tabla y gráfico de resultado del test 1.

54
UNIX. Incluso el uso de memoria es menor. La explicación se puede encontrar
en la compilación del kernel. No siendo el estudio del mismo parte de este
trabajo, sí se ha podido constatar tras la búsqueda de información que el núcleo
de Mac OS X tiene problemas de rendimiento provocados por el Kernel Mach.
El estudio [42], realizado por Jasjeet S. Sekhon6
demuestra que Linux maneja
mejor los bloques continuos de memoria de cierto tamaño (en su caso de 35
KB) frente a Mac OS X. Y pone de relevancia que dicho rendimiento se debe
a la compilación del kernel de ambos sistemas. De esta forma, Jasjeet S.
Sekhon ha constatado que una compilación del kernel cambiando el sistema de
gestión de memoria se consigue unos resultados idénticos en ambos sistemas,
pero no así con el sistema de gestión estándar de Mac OS X.
Uso de
Memoria
(%)
Rendimiento
(muestras/segu
ndos)
Tiempo de respuesta
(segundos) por
petición
Tiempo de respuesta
media de conjunto
(segundos)
Ubuntu 83 6,89 0,145 2,587
Windows 7 75 2,93 0,417 4,695
Mac OS X 80 3,77 0,265 4,081
Aunque no se ha recogido en los resultados anteriores, cabe mencionar que
en el segundo test realizado al sistema Ubuntu, en un momento dado el mismo
ha tenido que hacer uso de la memoria de intercambio o Swap, lo que ha
podido penalizar ligeramente su rendimiento. Esto se aprecia en la siguiente
6
Profesor de la universidad de Berkeley
0
1
2
3
4
5
6
7
8
9
10
uso de Memoria
(%)
Rendimiento
(muestras/sec)
Tiempo por
respuesta (sec)
Ubuntu
Windows 7
Mac OS X

55
captura del monitor de sistema (Figura 25). El uso es sólo del 0,1% por lo que
prácticamente es inapreciable el momento en el que el sistema utiliza dicha
memoria de intercambio.
También cabe reseñar que el uso de CPU en cada uno de los sistemas ha
sido del 100% en todos los casos, es decir, todos los test realizados utilizaban
el total de uso de la CPU mientras estaban en ejecución.
6.2. Cambio de configuración
Una vez realizado el test inicial se procede a realizar cambios en la
configuración de Apache y sus módulos para lograr un rendimiento óptimo.
En concreto, se utilizará como punto de partida la página de apache que
indica cómo mejorar el rendimiento [34].
Como indica el recurso mencionado hay que tener cuidado de no utilizar
swapping para ejecutar los procesos de apache, ya que aumentaría la latencia
de cada petición, lo que llevaría a los usuarios a recargar las páginas
incrementando la carga en el servidor.
En este Apache Performance Tuning (Mejora del rendimiento de Apache)
se indica una serie de recomendaciones dentro de la configuración del software
para conseguir aumentar el rendimiento. Estas modificaciones se realizan
dentro del fichero de configuración de apache (por defecto “apache2.conf”). A
parte de estos cambios se realizarán otro tipo de configuraciones que serán
comentadas más adelante.
A continuación se irán explicando cada uno de las configuraciones que
requiere Apache para lograr un mejor rendimiento, además en cada una de ellas
se indicará el rendimiento obtenido con el cambio o no modificación de la
Figura 25. Monitor Sistema Ubuntu (test 2).

56
configuración (los valores corresponden a peticiones/segundos que el servidor
procesa):
- Respecto a las consideraciones que se plantean, es recomendable
deshabilitar la resolución de nombres de los host, ya que en cada petición
habría que realizar la resolución de DNS antes de finalizarla, lo que
incrementa el tiempo de respuesta. Apache por defecto tiene deshabilitada
dicha función, pero cabe reseñar que la activación de la misma
comportaría un decremento del rendimiento. El comando a utilizar será
“HostnameLookups off”.
Test Ubuntu 10.10 Windows 7 Mac OS X
HostnameLookups off 7.10 2.93 3.85
HostnameLookups on 6.73 2.78 3.66
- Otra media es utilizar es la desactivación de enlaces simbólicos mediante
el comando “Options FollowSymLinks”, con ello evitamos que Apache
busque el contenido fuera de los directorios de la web. De distinta forma
ocurre con la directiva de negociación de contenido “MultiViews”. Si la
tenemos activada, cuando un usuario realiza una petición de una página en
un determinado idioma, Apache buscará dentro de los recursos dicha
página, por lo que hará que aumente la latencia a la hora de servir las
peticiones.
- De un modo similar, Apache cuando recibe una petición mira primero el
fichero “.htaccess” para ver si hay alguna configuración especial, y busca
en todos los subdirectorios hasta la raíz en busca de dicho archivo. Para
evitar esto utilizamos el comando “AllowOverride None”.
En el siguiente test se han utilizado las variables FollowSymLinks,
MultiViews y AllowOverride.
AllowOverride All
NO FollowSymLinks
MultiViews
6.89 2.93 3.77
AllowOverride None
FollowSymLinks
NO MultiViews
7.93 3.86 4.62

57
- Apache permite mantener conexiones permanentes por cada petición, de
manera que un usuario con la misma conexión puede obtener páginas html
y en la misma conexión obtener a su vez imágenes. Para ello hay que
activarlo (“KeepAlive on”) que es el valor por defecto de Apache. Además
se puede indicar el número de peticiones que se va a permitir con la misma
conexión (“MaxKeepAliveRequest 100”) y el tiempo de espera entre
peticiones antes de cerrar la conexión (“KeepAliveTimeout 15”). En el
caso de estudio, la aplicación web Wordpress, sólo se ha modificado el
valor para el tiempo de espera, en concreto se ha bajado dicho valor a
“KeepAliveTimeout 10”. De esta forma reducimos el tiempo de espera
para servir otra página a través de la misma conexión, y no mantenemos
conexiones a la espera de recibir una nueva petición.
KeepAlive off 6.33 2.45 3.42
KeepAlive on
MaxKeepAliveRequest 100
KeepAliveTimeout 10
6.92 2.92 3.78
- Compresión de las páginas. Se puede configurar Apache para que realice
la compresión de las páginas solicitadas. Con ello se reduce el tamaño de
las páginas descargadas entre un 30%-50% y por ende el tiempo de
conexión. En consecuencia, obtenemos un mejor rendimiento.
Para ello se utiliza el módulo de Apache “mod_deflate”. Lo único que
tenemos que hacer es habilitarlo mediante el comando “a2enmod deflate”.
Dicha compresión puede ser indicada para un solo directorio, un sitio o
todos los sitios del servidor. Dependiendo de lo que queramos comprimir
utilizaremos el comando ”SetOutputFilter DEFLATE” dentro de un
fichero .htaccess, dentro de la directiva “<directory>” en el fichero de
configuración del sitio o en el fichero de configuración de apache
“apache2.conf”.
Una vez que tenemos habilitado dicho módulo podemos configurar los
tipos de ficheros a comprimir.

58
Por defecto, dicho módulo comprime todas las páginas html, todos los
textos planos, los ficheros de estilo en cascada (“css”) y aplicaciones
JavaScript (“js”). Se pueden configurar para cualquier tipo de extensión,
pero excepto en las mencionadas, en la mayoría de las extensiones la
compresión es mínima por lo que no compensa hacer trabajar a la CPU
para dicha compresión.
Mod_deflate desactivado 6.92 2.94 3.77
Mod_deflate activado 7.17 3.12 3.89
- Para evitar que el servidor esté continuamente comprimiendo las páginas
solicitadas y con ello aumente la carga de trabajo, se puede utilizar el
módulo “mod_cache” junto con el módulo “mod_disk_cache”. Con la
utilización de estos módulos evitamos tener que estar continuamente
comprimiendo ciertas páginas estáticas.
Para habilitar los módulos creamos un enlace a los mismos en
“mods_enabled” y ejecutamos el comando “a2enmod cache” y “a2enmod
disk_cache”.
La configuración de la caché se encuentra en el fichero “disk_cache.conf”.
En este último, para que funcione la caché en disco, quitamos el
comentario a la línea “CacheEnable disk /”, y reiniciamos el servidor
apache. Con ello estamos cacheando todo el servidor web, pero se puede
cachear sólo un directorio.
Los únicos parámetros que aparecen por defecto y que son necesarios son:
“CacheDirLevels” que indica la creación de un árbol de directorios donde
se almacenan los ficheros cacheados ya que si estuvieran en el mismo
directorio penalizaría el rendimiento, y “CacheDirLength” que es el
número de caracteres de cada directorio. Dentro del módulo
“mod_disk_cache” se puede configurar las directivas tamaño máximo y
tamaño mínimo de los ficheros.
El módulo “mod_cache” tiene más directivas configurables, entre ellas
cabe destacar el tiempo de expiración de la caché. Esto es importante ya

59
que si no se actualiza la caché se corre el riesgo de que las páginas
servidas no estén actualizadas. Si las páginas están en continuo cambio, un
tiempo razonable puede ser 30 minutos.
Para limpiar de la caché los archivos que han expirado tenemos la
herramienta htcacheclean, que se instala junto con el módulo
mod_disk_cache. Se puede configurar dicha herramienta para que se
ejecute cada cierto tiempo (lo normal es que sea el mismo tiempo que el de
la expiración de las páginas cacheadas) mediante el comando
“htcacheclean -d30 -n -t -p /var/cache/apache2/mod_disk_cache -l 100M –
i”. De esta forma le indicamos que se ejecute cada 30 minutos (-d30) en el
directorio (-p “/../”) con un límite de almacenamiento de 100 MB (-l
100M). Además se especifica que se borre los directorios vacíos (-t) y que
el borrado sea inteligente (-i), de manera que sólo se ejecute cuando haya
una modificación en la caché del disco.
Respecto a la expiración de las páginas, también se puede utilizar el
módulo de Apache “mod_expires”, donde tenemos una mayor cantidad de
directivas para indicar parámetros más específicos.
mod_cache y
mod_disk_cache
desactivado
7.1 2.92 3.82
mod_cache y
mod_disk_cache activado 19.2 13.54 14.95
- Separar las páginas estáticas de las dinámicas. Este es otro aspecto a la
hora de mejorar el rendimiento de Apache. Apache al servir una página
dinámica utiliza unos 20-30 MB de memoria física. Una vez servida la
petición el proceso se queda a la espera de ejecutar otra petición en la
misma conexión para evitar realizar continuas conexión. Si la siguiente
petición es una imagen, esta petición está utilizando esos 30 Mb de
memoria física cuando sólo requiere de unos cuantos Kb. La solución
que se puede efectuar es la de separar las páginas dinámicas de las
estáticas. Para ello se utilizará los módulos mod_proxy y mod_rewrite.

60
Además hay que tener instalado un segundo servidor para que uno se
encargue de servir las páginas estáticas (servidor ligero) y el otro sirva
las páginas dinámicas (servidor pesado).
Como servidor ligero se utilizará lighttpd, el mismo simplemente tendrá
configurado el puerto 81 y el directorio donde se encuentra Wordpress.
No tendrá ningún parámetro específico ya que simplemente se le pasará
las páginas html, las imágenes, las hojas de estilo (css) y los JavaScript
(js).
Como servidor web pesado se utilizará Apache, el cual tendrá toda la
configuración descrita a lo largo de este documento.
Respecto a la configuración que tendrá Apache, ya bien sea en el archivo
de configuración general (apache.conf) o dentro de las directivas de un
directorio, para pasar las extensiones de un servidor a otro será la
siguiente:
· “RewriteEngine On”, activamos el módulo mod_rewrite
· Creamos la regla para indicar todas las imágenes y fichero estáticos
que se enviarán al servidor ligero {RewriteRule
^/(.*).(jpg|jpeg|gif|png|swf|
pdf|avi|mpeg|mpg|mp3|tgz|gz|css|html|js)$""http://127.0.0.1:81/$1.$2"
[P]}
· Con el siguiente comando, “ProxyPassReverse / http://127.0.0.1:81”,
indicamos que se envíe todo lo anterior al servidor ligero que escucha en
el puerto 81 y que envíe la cabecera http para seguir utilizando los
cookies. De esta forma el usuario no percibe si se está proporcionando las
páginas desde un servidor u otro.
Con este tipo de configuración se mejora sobre todo en el uso de
memoria física. Respecto al rendimiento depende de la cantidad de
ficheros estáticos que se pueden servir desde distintos servidores.
Mod_proxy y mod_rewrite
desactivado 7.10 2.93 3.77
Mod_proxy y mod_rewrite
activado 8.05 3.87 4.6

61
- Un aspecto importante a la hora de mejorar el rendimiento es elegir
correctamente los parámetros del módulo MPM (Multi-Processing
Modules. Módulos de Procesamiento Múltiple). Hay módulos de
procesamiento específicos para algunas plataformas, por ejemplo para
Windows el módulo es “mpm_winnt”, que según la descripción de la
página oficial de Apache crea un solo proceso hijo el cual crea tanto
Threads (hilos) según el número de peticiones.
En cambio para plataformas de tipo UNIX se puede elegir entre varios
MPM, lo que puede afectar al rendimiento de Apache. Estos MPM son:
Prefork y Worker. La diferencia entre ambos radica en que mientras en
Prefork se crean varios procesos hijos, utilizando uno por cada petición
que se realiza, en Worker se crean varios procesos hijos con varios
Threads cada uno, utilizando para cada petición un Thread. Este último
es utilizado principalmente para equipos multiprocesadores y tiene un
menor consumo de memoria respecto a Prefork.
El MPM a utilizar será Worker en el caso de los sistemas UNIX, que para
que funcione con php requiere del módulo mod_fcgid. Se ha decidido
utilizar este MPM porque una buena forma de lograr un buen
rendimiento en los sistemas Windows es utilizar FastCGI, ya que tiene
más ventajas que ejecutarlo como controlador o como CGI, por eso los
resultados obtenidos en dicho test respecto a Windows reflejan el
comportamiento de FastCGI. Por ende, para que todos los sistemas
utilicen los mismos módulos, siempre que se pueda, se ha decidido a
utilizar dicho MPM.
Además tras realizar varias pruebas con ambos módulos, el módulo
MPM Worker obtiene mejores resultados que el módulo MPM Prefork.
Para utilizar el MPM Worker hay que instalar los módulos apache2-
mpm-worker y libapache2-mod-fcgid, y habilitaremos el módulo fcgi con
el siguiente comando “a2enmod fcgid”.
Los parámetros de configuración utilizados para los módulos fcgi y
Worker, se han obtenido de los artículos de 2bits7
[39], de la web de
7
2bits es una empresa privada de consultoría especializada en el sistema gestor de contenidos Drupal.

62
RedHat8
[40], y en el libro de “La Biblia de Servidor Apache2” de
Mohammed J. Kabir [41].
Los servidores hijo utilizados al comenzar Apache (StartServers) serán 3,
con un máximo (ServerLimit) de 3000. Esto se produce en los sistemas
UNIX, mientras en los sistemas Windows, cómo se ha comentado más
arriba, la versión de Apache es multihilo, por lo que un solo proceso
maneja todas las solicitudes, de esta forma lo único que podremos
configurar será el límite de hilos.
Cada proceso hijo puede generar a su vez un hilo, estableciéndose un
límite de 25 hilos por proceso (ThreadsPerChild).
Respecto al máximo de solicitudes simultáneas que el servidor puede
procesar (MaxClients), se establece en 300 peticiones concurrentes.
Se fija un máximo de 10 hilos en espera (MaxSpareThreads).
También cabe mencionar que el límite de solicitudes que puede procesar
un servidor hijo (MaxRequestPerChild) es configurado a 0, por lo que
estos procesos nunca mueren.
mpm Prefork activado 7.1 2.93 3.78
mpm_worker activado 18.5 15.4 15.8
Además se han realizado distintas pruebas con los parámetros
configurables de Worker. No aparecen los valores para Windows porque
no utiliza dicho módulo.
Variables Valores por Defecto Valores
StartServer 2 5 500 100 5
ThreadsPerChild 25 25 10 15 10
MinSpareThreads 25 5 3 3 3
MaxSpareThreads 75 15 10 50 10
MaxClients 150 300 300 150 150
MaxRequestChild 0 0 1000 1000 0
Ubuntu 10.10 18.5 16.8 18.5 19 18.3
Mac OS X 15.8 14.8 15.7 15.8 15.7
8
Sistema operativo basado en Linux al igual que Ubuntu.

63
Para aglutinar todas las variables que se han modificado en Apache para
obtener un mejor rendimiento, se ha creado el siguiente resumen
mediante la siguiente tabla.
VARIABLE PARÁMETROS DESCRIPCIÓN
HostnameLookups No
Deshabilita la resolución de
nombres de los equipos que
realizan peticiones
FollowSymLinks Activada
Evitamos que Apache busque un
contenido fuera de su directorio.
Multiviews Desactivada
Si no utilizamos esta directiva
evitamos la negociación de
contenido en otros idiomas.
AllowOverride None
Evita que Apache realice una
búsqueda por todas las carpetas
hasta la raíz del fichero de
configuración .htaccess
KeepAlive On
Habilita la espera en la conexión
para realizar varias peticiones con
la dicha conexión
MaxKeepAliveRequest 100
Establece el límite de peticiones
que puede procesar una conexión
KeepAliveTimeout 10
Establece el tiempo máximo de una
conexión antes de cerrarse si no
recibe una nueva petición.
mod_deflate Activado
Si activamos dicho módulo se
realizará la compresión de las
páginas solicitadas
mod_cache,
mod_disk_cache
Activado
Con la activación de estos módulos
las páginas solicitadas serán
cacheadas en el disco.
mod_proxy,
mod_rewrite
Activado
Con estos dos módulos se puede
realizar la separación de las páginas
estáticas de las dinámicas. Para ello
necesitamos un 2º servidor web
mpm_prefork,
mpm_worker
El elegido por
rendimiento es
mpm_worker
Estos módulos están disponibles en
la versión de UNIX, y cada uno
realiza una gestión de los procesos
de manera diferente.
StartServer 3
Número de servidores hijo con los
que Apache inicia al recibir una
petición
ServerLimit 3000
Límite de servidores hijo que puede
utilizar Apache
ThreadsPerChild 25
Hilos que pueden generar cada
servidor hijo
MaxClients 300
Número máximo de peticiones
concurrentes que Apache procesa
MaxSpareThreads 10 Número máximo de hilos en espera
MaxRequestChild 0
No se establece límite del número
de solicitudes que un servidor hijo
puede procesar
Figura 26. Resumen cambios realizado en Apache.

64
Sin querer adelantarnos a los resultados de los test, tras una prueba para
comprobar los resultados en cuanto a la diferencia de rendimiento entre los dos
distintos módulos MPM en los sistemas UNIX, cabe reseñar que la cantidad de
memoria consumida (Figura 27) ante una prueba de 50 usuarios simultáneos
con el módulo MPM Worker y el módulo fcgid, es prácticamente la mitad a la
utilizada con el MPM Prefork, que fue el utilizado en los test de inicio.
Aprovechando que los sistemas están instalados en máquinas virtuales, se
pueden utilizar distintas configuraciones en cuanto a memoria y CPU se
refiere. Por tanto realizaremos distintas configuraciones para ver el rendimiento
con escenarios diferentes. Las configuraciones que podemos utilizar son: la
configuración de memoria física, se configurarán los sistemas pertinentes
aumentando o disminuyendo su valor, así si actualmente los sistemas disponen
de 2 GB, se pueden realizar configuraciones desde 256 MB a 3.5 GB que es el
máximo disponible, y la otra variable a cambiar sería el procesador, donde
existe la posibilidad de configurar 1, 2, 4, u 8 procesadores, con 1, 2, 4, u 8
Core cada procesador. En este caso debido al hardware disponible sólo se
pueden utilizar dos configuraciones: 1 procesador o 2 procesadores, que es lo
máximo que puede soportar el equipo utilizado.
6.3. Test Final
Antes de realizar todos los cambios de Apache y realizar los respectivos
test, es conveniente ver cómo afecta cada cambio en la configuración en cada
uno de los sistemas, aunque en algunos de los test se utilizarán varias variables.
Figura 27. Monitor Sistema Ubuntu con 50 usuarios concurrentes.

65
Por tanto, la siguiente información (Figura 27) recoge el rendimiento antes de
los cambios y después de los cambios.
Una vez implementado dichos cambios en la configuración de Apache y
sus módulos, se crearán varias pruebas para conocer el comportamiento de
cada uno de los sistemas. De esta forma se podrá tener una idea más clara de
cuál de ellos gestiona mejor los procesos y la memoria física, así como quien
obtiene mejor tiempo de respuesta ante una petición.
Al igual que se realizó en el test inicial, las herramientas de benchmark
serán las mismas (ab y JMeter), y los parámetros a utilizar los ya descritos en
los test inicial. Aunque en este caso sólo se realizará los test con 50 usuarios
concurrentes para compararlos con los realizados en el test inicial.
Tras examinar los resultados de los diferentes test realizados, se han
plasmado en la siguiente tabla y gráfica (Figura 28).
Uso de
Memoria (%)
Rendimiento
(muestras/segundos)
Tiempo de respuesta
media de conjunto
(segundos)
Ubuntu 40 27,6 0,905
Windows 7 65 15,9 1,433
Mac OS X 43 16,3 1,373
Rendimiento (peticiones/sec)
Ubuntu
Windows 7
Mac OS X

66
Como se aprecia en la tabla, sólo se recoge el tiempo medio del conjunto
de páginas analizadas. Esto se debe a que en la configuración de los servidores
se ha utilizado el módulo caché. Debido a tal causa, los test realizados sobre
una única página, nos daban resultados del orden de 100 veces mayor
rendimiento, mientras que el test realizado sobre un conjunto de páginas no
daba tal valor, por lo que podría llegar a no entenderse bien los resultados.
De todas formas se mostrarán los resultados de los test realizados sobre
una sola página para compararlos entre los sistemas.
La lectura principal que se puede hacer de los resultados es la reducción en
el consumo de memoria en todos los sistemas. Entre otros, la separación entre
páginas dinámicas y estáticas, junto con el módulo de caché de disco, según se
ha podido apreciar, son los que más han contribuido a tal reducción.
Otra lectura que podemos realizar es que Ubuntu se posiciona como el
mejor sistema para ejecutar un servidor web Apache a la hora de servir páginas
web dinámicas e incluso estáticas, prácticamente obtiene el doble de
rendimiento frente a los demás sistemas.
La siguiente muestra obtenida con el apache benchmark, se observa lo ya
comentado del rendimiento, el cual es mucho mayor que los obtenidos hasta
ahora. La razón es la de ser una simple página estática y no una página
dinámica.
Rendimiento
(muestras/segundos)
Tiempo de respuesta
(ms)
Ubuntu 2681.54 3.72
Windows 7 626.67 16.45
Mac OS X 1439.84 6.45
Para conocer cuál de los tres sistemas tiene mejor respuesta a la
escalabilidad de las peticiones de páginas, se han realizado los mismos test
pero con una carga de trabajo mayor, es decir, se han realizado test con 100
usuarios concurrentes y 200 usuarios concurrentes. Ambos test han realizado la
petición de las páginas de la secuencia descrita en la figura 20.
Figura 29. Tabla de resultado del test páginas estáticas.

67
Peticiones concurrentes 50 100 200
Ubuntu 10.10 27.6 28.0 31.6
Windows 7 15.9 15.9 15.7
Mac OS X 16.3 16.5 16.8
Por lo que se aprecia en los resultados, se puede decir que los sistemas
basados en UNIX tienen una mejor respuesta al aumento de peticiones con la
configuración descrita en estos apartados que el sistema Windows.
Probablemente se deba a la gestión de la memoria que realizan dichos sistemas,
ya que
7. Análisis de resultados
Ante los datos obtenidos de los test, se confirma como el sistema operativo
Ubuntu reacciona mejor ante la petición de una solicitud al servidor web Apache.
Esto no quiere decir que los otros dos sistemas puedan dar una mayor prestación en
otro tipo de escenario.
Aun cuando el sistema Ubuntu ha sido el único que, en un momento dado de los
test9
, ha necesitado usar la memoria Swap para poder servir los procesos que en ese
momento requerían de algún tipo de memoria para ejecutarse, en todos los demás test
el comportamiento de uso de la misma ha sido totalmente superior a los demás.
Este cambio, como se ha podido constatar a lo largo de la configuración y
modificación de Apache, se debe sobre todo al cambio en el módulo de
procesamiento múltiple (MPM), pasando del módulo Prefork al módulo Worker, y la
instalación del módulo fcgid (necesario para la ejecución de php). Este último
presenta una menor estabilidad frente al módulo mod_php, pero ha sido necesaria su
utilización para poder utilizar el módulo Worker.
Con este módulo lo que se logra es que el servidor web Apache pase las
peticiones a la aplicación FastCGI, que se ejecuta fuera del mismo. El módulo
Worker no requiere de un proceso por petición, como ocurría en el caso de Prefork,
sino que un proceso hijo puede crear tantos subprocesos o hilos como peticiones
haya.
9
Página 44 de este trabajo, se puede observar en la figura 24.
Figura 30. Tabla de resultado de test con distintos usuarios.

68
En los sistemas UNIX (Figura 31), cuando realizamos varias peticiones, en este
caso son 50 usuarios concurrentes, se inician 3 procesos de apache (configurado en la
opción del módulo Worker), que a su vez crean los respectivos procesos de la
aplicación FastCGI.
Además, se puede apreciar como cada proceso php-cgi ocupa una media de 32
MB (columna RES) de memoria física, sin embargo los procesos de Apache
simplemente ocupan unos cuantos KB. Con el módulo Prefork se creaba un proceso
de Apache de unos 27 MB por cada una de las peticiones. Al tener 50 peticiones, si
las multiplicamos por el valor de memoria de cada proceso es lo que provoca que el
consumo de memoria se dispare. Por tanto la mejor configuración respecto a la
gestión de memoria es la utilización del módulo Worker.
En el sistema Windows no podemos configurar estos parámetros. El módulo
utilizado es mpm_winnt, donde sólo se puede configurar el máximo de hilos que un
proceso puede crear, por lo que se crearán tantos hilos como peticiones se realicen.
El consumo de memoria es mayor en los sistemas Windows que en los sistemas
UNIX. Además como se ha podido constatar, los sistemas UNIX consumen un 10%
menos de memoria que los sistemas Windows en cuanto a la memoria necesaria para
la ejecución del propio sistema.
Respecto a la mejora de consumo de memoria, se puede decir que todos los
sistemas han mejorado mediante la configuración de un segundo servidor que sirva
Figura 31. Procesos obtenidos con el comando Top en Ubuntu.

69
las páginas estáticas. De este modo todas las peticiones que lleven consigo una
imagen, un fichero html, etc. serán servidas por un segundo servidor, en este caso por
el servidor lighttpd. De esta forma todas las peticiones a imágenes, páginas estáticas,
páginas de estilo no utilizarán un proceso de apache, sino que serán servidas por el
servidor ligero lighttpd, cuyos procesos ocupan una mínima parte de la memoria
física. Aunque como ya se ha comentado, la utilización del mpm_Worker o FastCGI
ha contribuido más a la mejora de dicha utilización.
También cabe decir que ante una escalabilidad de los usuarios concurrentes, el
sistema Windows tiene peor respuesta frente a los demás, debido probablemente a la
utilización de la memoria que realiza dicho sistema frente a los demás.
En conclusión, en este análisis se puede decir que los sistemas UNIX tienen un
mayor control de los procesos, en cuanto que Windows concentra todas las
peticiones en un solo proceso. Pero hay que decir, que el uso de FastCGI en los
sistemas UNIX puede ocasionar problemas a la hora de ejecutar las páginas PHP
siempre que éste no disponga de su propio espacio de memoria [43]. Algo que no le
ocurre a Windows por ser un sistema multi-hilo.
Se puede concluir por tanto que el sistema operativo Ubuntu es el más idóneo de
los tres sistemas evaluados para ser utilizado como servidor de páginas web,
utilizando para ello el servidor Apache.
8. Conclusiones
El trabajo final de carrera ha consistido en la evaluación del rendimiento de tres
sistemas operativos. Los sistemas escogidos son de uso común: Windows 7
Profesional, Ubuntu 10.10 y Mac OS X 10.6, por lo que no se ha buscado qué
sistema de todos los existentes en el mercado proporciona mejor rendimiento.
Dicho trabajo ha estado comprendido en varias fases, las cuales, estando
relacionadas unas con otras, comportaban distintos retos a conseguir. En una primera
fase teórica, he podido profundizar en cómo gestionan los procesos y la memoria los
sistemas que utilizamos a diario, y comprender por qué unos sistemas realizan la
misma labor de forma diferente. Por ejemplo, algunos sistemas Windows no
reconocen 4 GB de memoria RAM, y es que al ser sistemas de 32 bits, su espacio de
direcciones está limitado a 4 GB. Otro ejemplo es porqué en Windows aparece sólo

70
un proceso en ejecución de Apache cuando tiene varias solicitudes simultáneas,
mientras que en UNIX aparecen varios procesos siendo la misma situación.
El resto del trabajo ha sido mayoritariamente práctico, lo que contribuye a que el
mismo haya sido más agradable de realizar, pero no exento de problemas y búsqueda
de información.
En esta parte práctica se ha tenido que ir salvando distintos obstáculos, como la
instalación de los sistemas en máquinas virtuales y la configuración del servidor
Apache en los mismos. Ambas tareas no eran nuevas para mí, excepto el caso del
sistema Mac OS X, el cual nunca lo había instalado en una máquina virtual, y mucho
menos utilizado como servidor web.
Unos de los primero problemas encontrados ha sido la de intentar utilizar como
Hypervisor la versión VMWare ESXi [15]. Este Hypervisor, tanto por ser gratuito
como por las prestaciones que suele proporcionar, era la primera elección, pero
debido a la incompatibilidad con el hardware disponible para el trabajo no ha sido
posible su instalación, por lo que se ha tenido que utilizar la versión VMWare
Workstation [16]. Cabe decir que podríamos haber utilizado cualquier otro
Hypervisor existente en el mercado.
Dentro de los retos a los que he tenido que enfrentarme en este trabajo he de
destacar dos de ellos por el tiempo que me ha supuesto a la hora de conseguirlos, y
por ende por los problemas que me han ocasionado. Se trata de lograr una
configuración de Apache que obtuviera el máximo rendimiento del mismo mediante
la separación de las peticiones estáticas de las dinámicas y la elección del módulo
MPM como módulo de multiprocesamiento. Han sido las dos metas logradas con
mayor esfuerzo.
Considero que el objetivo del trabajo ha sido cumplido, en tanto que se ha
podido comprobar cuál de los tres sistemas obtiene mejor rendimiento ante un mismo
problema.
A nivel personal, me llevo la satisfacción de haber realizado un trabajo que está
relacionado con mi actividad profesional actual. Me refiero sobre todo a la
configuración de Apache como servidor web y a las configuraciones que se pueden
realizar en el mismo para obtener el máximo rendimiento. Ya que hasta la fecha los
conocimientos sobre el tema estaban lejos de lo aprendido con el trabajo.

71
9. Bibliografía y enlaces
Sistemas Operativos:
[1] Tanenbaum Andrew S. (2003): Sistemas Operativos Modernos. (2ª Edición) México: Prentice
Hall
[2] Héctor Jairo Ortiz Pabón (2005): Sistemas Operativos Modernos. (1ª Edición) Medellín-
Colombia: Sello
[3] Tanenbaum Andrew S. (1996): Sistemas Operativos Distribuidos. (1ª Edición) México:
Prentice Hall
[4] Irene Rodil Jiménez y Camino Pardo de Vega (2010): Operaciones auxiliares con tecnologías
de la información y la comunicación. (1ª Edición) Madrid: Paraninfo
[5] API Windows: http://msdn.microsoft.com/en-us/library/aa383749(v=vs.85).aspx
[6] Sistema Operativo Ubuntu: http://www.ubuntu.com/
[7] Sistema Operativo Mac OS X: http://developer.apple.com/library/mac/navigation/
[8] Sistema Operativo Microsoft: http://www.microsoft.com/es/es/default.aspx
[9] Sistema UNIX: http://www.unix.org/
[10] Tienda de Microsoft: http://emea.microsoftstore.com/es/es-ES
[11] Servidor Web Apache: http://www.apache.org/
Máquinas Virtuales:
[12] http://es.wikipedia.org/wiki/M%C3%A1quina_virtual
[13] VMWare: http://www.vmware.com/es/
[14] VMWare Server: http://www.vmware.com/products/server/overview.html
[15] VMWare ESXi: http://www.vmware.com/products/vsphere-hypervisor/overview.html
[16] VMWare WorkStation: http://www.vmware.com/products/workstation/
[17] Máquina Virtual XEN: http://www.xen.org/
[18] Máquina Virtual, Virtual Box: http://www.virtualbox.org/
[19] Máquina Virtual Virtual-PC: http://www.microsoft.com/windows/virtual-pc/
[20] Servidor Hyper-V: http://www.microsoft.com/hyper-v-server/en/us/default.aspx
[21] Sun: http://www.oracle.com/us/sun/index.html
[22] Máquina Virtual Java (JVM): http://www.java.com/es/about/

72
[23] Framework de Microsoft .NET: http://www.microsoft.com/net/
Benchmarking:
[24]¿Qué es el benchmarking? http://www.elblogsalmon.com/conceptos-de-economia/que-es-el-
benchmarking
[25] Software de test JMeter: http://jakarta.apache.org/jmeter/
[26] Software de test Apache Benchmark (ab): http://httpd.apache.org
[27] Descarga de Mysql : http://dev.mysql.com/downloads/mysql/
Sistemas Virtuales:
[28] Virtuozzo: http://www.parallels.com/es/products/pvc46/
[29] Linux-VServer: http://linux-vserver.org/Welcome_to_Linux-VServer.org
[30] Solaris Containers: http://www.oracle.com/technetwork/systems/containers/index.html
[31] OpenVZ: http://wiki.openvz.org/Main_Page
[32] FreeBSD Jails: http://www.freebsd.org/
[33] Ranking servidores web http://news.netcraft.com/
Mejora del rendimiento de Apache:
[34] Performance Tuning Apache: http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
[35] Máximo rendimiento de Apache:
http://www.howtoforge.com/configuring_apache_for_maximum_performance
[36] Rob Flickenger (2003): Linux Server Hacks. (1ª Edición) EE.UU.: O'Reilly Media
[37] Módulo Prefork de Apache: http://httpd.apache.org/docs/2.0/mod/prefork.html
[38] Módulo Worker de Apache: http://httpd.apache.org/docs/2.0/mod/worker.html
[39] Apache con fcgi: http://2bits.com/
[40] Directrices MPM específicas: http://docs.redhat.com/docs/es-ES/Red_Hat_
Enterprise_Linux/5/html/Deployment_Guide/s2-apache-mpm-containers.html
[41] Mohammed J. Kabir (2002): La Biblia de Servidor Apache 2. Madrid: Anaya
[42] Linux versus Mac OS X en Intel Core http://sekhon.berkeley.edu/macosx/
[43] Instalación de PHP http://php.net/manual/es/faq.installation.php

D3 gestión de sistemas operativos

Más contenido relacionado

La actualidad más candente (17)

Destacado (7)

Similar a D3 gestión de sistemas operativos (20)

Más de mariopino129 (14)

Último (20)

D3 gestión de sistemas operativos