XIV JORNADAS DE PARALELISMOLEGANES, SEPTIEMBRE 2003 1

ResumenEl desarrollo de nuevas mejoras arquitectnicas

depende, en gran medida, de la disponibilidad de
herramientas de simulacin fiables y cargas de trabajo
representativas que permitan conocer su efectividad real.
En este trabajo estudiaremos una metodologa de
simulacin de cargas de trabajo transaccionales de tipo
ayuda a la toma de decisiones en entornos de simulacin de
sistema completo. Para permitir reducir el tiempo de
simulacin estudiaremos la estacionaridad de este tipo de
aplicaciones. Basndonos en dicha estacionaridad
mostraremos como considerando nicamente un 5% de la
ejecucin del benchmark completo el error obtenido en las
principales figuras de rendimiento del sistema esta por
debajo del 3%.
Palabras clave TPC-H, IRIX, SimOS, PostgreSQL, DSS,
SGBD, jerarqua de memoria, sistema de interconexin.
I. INTRODUCCIN
ASTA hace relativamente pocos aos, los grandes
sistemas de computacin han sido utilizados casi
exclusivamente para procesar cargas numricas. Sin
embargo en los ltimos aos se observa un cambio de
tendencia en dichos usos [1]. Un porcentaje cada vez
ms relevante de los grandes sistemas de computacin
est siendo dedicado a cargas de trabajo de tipo
transaccional. Ante esta situacin, las grandes
compaas de hardware y software han fomentado la
aparicin de nuevos estndares de benchmark .
Para proveer al mercado y a los desarrolladores de
herramientas de benchmarking que permitan conocer el
impacto de cargas transaccionales, se forma el
Transaction Processing Performance Council (TPC)
[2]. Uno de los estndares promovidos por dicha
organizacin es el estndar TPC-H. Este estndar simula
un sistema de ayuda a la toma de decisiones (Decision
Support System o DSS) en sincronizacin con un
sistema de procesado de transacciones en lnea (On-Line
Transaction Processing u OLTP).
La metodologa de desarrollo de nuevas propuestas
arquitectnicas requiere de la utilizacin de simuladores
para su evaluacin. Debido a que los sistemas de alto
rendimiento orientaban su uso al clculo numrico, la
mayor parte de las cargas de trabajo empleadas
habitualmente se centran en este escenario .
Es necesario ampliar el marco de trabajo
contemplando la posibilidad de emplear cargas de tipo
transaccional en esta clase de anlisis. Para poder

1
Este trabajo ha sido financiado por la Comisin Interministerial de
Ciencia y Tecnologa (CICYT), proyecto TIC-2001-591-C02-01
2
Grupo de Arquitectura y Tecnologa de Computadores,
Universidad de Cantabria. {lamigo,vpuente,jagm}@atc.unican.es

simular benchmarks transaccionales se requiere simular
el sistema completo, incluyendo todos los elementos
hardware y software que intervienen (Sistema operativo
y sistema gestor de la base de datos). Lgicamente para
determinar el impacto de una mejora arquitectnica los
requerimientos computacionales pueden ser
extraordinariamente elevados. Para reducirlos es
necesario reducir la complejidad del problema sin alterar
su representatividad. En aplicaciones numricas esta
reduccin se realiza mediante el escalado del tamao de
la carga y de las caractersticas de los elementos del
sistema. En cargas transaccionales, esto no es posible
debido a que no se puede encontrar una relacin clara
entre el tamao de la carga y la cantidad de trabajo.
Proceder de este modo puede alterar completamente las
caractersticas propias de la carga. En este trabajo
mostraremos como es posible atenuar la demanda
computacional de una carga de este tipo sin perdida de
representatividad. Se mostrar como, a diferencia de lo
que ocurre en las cargas de tipo numrico, el
comportamiento es estable a lo largo de la ejecucin de
la aplicacin. Tomando en consideracin este hecho es
posible analizar tan solo una parte de su ejecucin para
poder determinar el impacto global de una posible
mejora arquitectnica con una demanda computacional
substancialmente menor a la que correspondera a la
ejecucin del benchmark completo.
En la seccin 2 se mostrarn las principales
diferencias existentes entre las cargas numricas y
transaccionales y como pueden afectar a la metodologa
de estudio. En la seccin 3 se describir el benchmark
considerado en este estudio as como su
implementacin. En la seccin 4 se detallar el entorno
empleado. En la seccin 5 se indicarn los resultados
obtenidos. Por ltimo, en la seccin 6 se apuntarn las
principales conclusiones que se desprenden de este
trabajo
II. CARGAS NUMRICAS FRENTE A CARGAS
TRANSACCIONALES.
El esquema de ejecucin de las cargas numricas
genera patrones de comportamiento que se pueden
resumir en sucesivas fases de clculo y comunicacin
intercaladas entre s. Este patrn de comportamiento
hace necesaria la completa ejecucin de la carga para
caracterizar su impacto sobre el sistema. Como la mayor
limitacin de un entorno de simulacin es su elevada
demanda computacional, la forma de introducir este tipo
de cargas en dicho entorno pasa por el correcto escalado
del tamao del problema y los parmetros
arquitectnicos del sistema simulado [3]. Este tipo de
escalados es posible debido la relacin clara que existe
Metodologa de Simulacin para Cargas
Transaccionales DSS
1
.
Luis Amigo, Valentn Puente, Jos A. Gregorio
2
.
H
2 AMIGO, PUENTE Y GREGORIO: METODOLOGA DE SIMULACIN PARA CARGAS TRANSACCIONALES DSS.

entre el patrn de clculo y comunicacin del problema
con el tamao del mismo.
Por otro lado, el esquema de ejecucin de las cargas
transaccionales presenta una fase de establecimiento de
las conexiones, una fase de ejecucin de las consultas y
una fase de finalizacin de las conexiones. Las fases de
establecimiento y finalizacin de conexiones pueden
considerarse como transitorios de inicio y fin de
ejecucin, mientras que el patrn de clculo durante la
fase de ejecucin presenta un comportamiento
estacionario. Sin embargo, en este tipo de cargas, la
cantidad de clculo y comunicacin no resulta sencilla
de relacionar con el tamao del problema.
La cantidad de trabajo de un sistema transaccional, as
como su patrn de ejecucin, depende de la complejidad
de la base de datos sobre la que se trabaje. Un mismo
esquema de relaciones en una base de datos puede dar
comportamientos diametralmente opuestos en funcin
de la cantidad de datos de las tablas. En un sistema DSS
se realizan consultas que abarcan un gran nmero de
tablas. En funcin de la cantidad de referencias cruzadas
entre dichas tablas, variar la cantidad de trabajo que se
ha de realizar para obtener el resultado de la consulta.
Imaginemos un caso sencillo en el que se desea
interrelacionar dos tablas en funcin de una nica
condicin, si no existiese ninguna entrada que cumpla la
condicin en la primera tabla, no sera necesario buscar
ocurrencias en la segunda. Este hecho hace que sea
necesario tener mucho cuidado a la hora de seleccionar
el tamao de los datos incluidos en la base de datos.
Por otro lado, el planificador realiza estimaciones
sobre el contenido de los datos para elegir el mtodo de
resolucin de una consulta. As, en funcin del nmero
de ocurrencias que estime que va a haber en una tabla, y
de su distribucin, se resolver dicha consulta con
mtodos secuenciales o ndices. Es decir, si el
planificador estima que el nmero de ocurrencias de
datos, que cumplan una determinada condicin, es
reducido, utilizar ndices para obtener los resultados.
En cambio si estima que el nmero de resultados ser
elevado, o que estos se hallan fsicamente contiguos,
utilizar accesos secuenciales.
El uso de ndices para resolver las consultas, agiliza las
operaciones si el tamao de la carga es elevado, pero
como contrapartida, provoca bloqueos entre los distintos
procesos, puesto que dos consultas no pueden acceder
simultneamente a un mismo nivel de un ndice. Si se
tuviera una base de datos reducida, el planificador de
consultas optara siempre por mtodos secuenciales, al
encontrarse los datos fsicamente contiguos, lo que dara
un comportamiento distinto al de las cargas de trabajo
reales.
Todo esto provoca que, para mantener el patrn de
comportamiento de las cargas transaccionales, sea
necesario mantener tambin un tamao de base de datos
que asegure que habr ocurrencias en todas las
condiciones, y que sigan emplendose ndices para
agilizar las consultas.
El tipo de operaciones realizadas en cargas de trabajo
numricas muestra una escasa dependencia con el
sistema operativo, debido a que el uso de
funcionalidades del sistema se reduce al uso del espacio
de memoria virtual. Debido a esta escasa dependencia
no suele ser habitual incluir el impacto del sistema
operativo en el estudio del sistema bajo anlisis en estas
condiciones, simplificndose as enormemente el
proceso de simulacin.
Por el contrario, en cargas de trabajo transaccionales,
aparece una elevada dependencia con el sistema
operativo [4]. Dicha dependencia se debe,
principalmente, al mecanismo de comparticin de datos
entre los distintos procesos y al elevado uso que, este
tipo de cargas, hacen de los elementos de disco, y por
ello, de los mecanismos de sincronizacin y cache del
acceso a disco proporcionado por el sistema. Esta
elevada dependencia de los sistemas gestores de base de
datos (SGBD) con el sistema operativo, obliga a que sea
necesario incluir su impacto dentro las simulaciones de
cargas transaccionales.
Para reflejar el impacto del sistema operativo en ste y
otro tipo de cargas, surge lo que se conoce como
simuladores de sistema completo. Estos entornos de
simulacin reflejan, con un elevado grado de detalle,
todos los elementos de un sistema computacional de tal
manera que se puede ejecutar en ellos sistemas
operativos comerciales. Uno de estos entornos de
simulacin es SimOS [5], desarrollado en la Universidad
de Stanford en 1996. SimOS simula arquitecturas
basadas en procesadores MIPS, Alpha y Power PC, de
tal manera que permite ejecutar versiones modificadas
de los sistemas operativos IRIX, Digital y AIX.
III. LA CARGA DE TRABAJO.
El estndar TPC-H [6] modela un sistema de ayuda a
la toma de decisiones de una gran corporacin
multinacional. Este sistema incluye una base de datos
que representa clientes, proveedores, pedidos y artculos
de la corporacin en 25 pases y 5 regiones geogrficas.
El sistema DSS se sincroniza peridicamente con un
sistema de transacciones en lnea, que procesa los
nuevos pedidos y las modificaciones sobre los pedidos
ya existentes. Esta sincronizacin se modela con la
inclusin de nuevos datos y el borrado de datos
obsoletos en lo que se conoce como funciones de
refresco.
Sobre esta base de datos se realizan dos tests cuya
media geomtrica representa el resultado del benchmark.
El primer test, conocido como Power Test, se basa en
la ejecucin secuencial de las funciones de refresco y de
lo que se conoce como stream. Un stream es la
ejecucin secuencial de 22 consultas DSS complejas
desde una nica conexin. El objetivo de este test es
medir la velocidad de respuesta del sistema en el mejor
caso.
En el segundo test, conocido como Throughput Test,
se ejecutan varios streams concurrentemente con las
funciones de refresco. El objetivo de este test es la
medicin de la capacidad de respuesta del sistema en
una situacin de carga elevada.
El tamao de la base de datos sobre la que se realiza el
benchmark depende de un parmetro conocido como
factor de escala. El factor de escala es un multiplicador
sobre el tamao base del sistema, que corresponde a 1
GB de datos en crudo. El factor de escala se elegir en
funcin del rea del mercado a la que est orientado el
sistema. Este tamao de datos en crudo multiplica varias
XIV JORNADAS DE PARALELISMOLEGANES, SEPTIEMBRE 2003 3
veces su valor una vez que se introduce en un esquema
relacional. El aumento que se produce vara en funcin
de los mecanismos de seguridad que se suministren, logs
de recuperacin, replicacin de datos
A. Implementacin del benchmark .
Para realizar un benchmark siguiendo las
especificaciones TPC-H se ha utilizado como SGBD
PostgreSQL [7]. Se trata de un sistema gestor de base de
datos desarrollado originalmente en la Universidad de
Berkeley. El objetivo de este proyecto es realizar un
SGBD libre que ofrezca funcionalidades similares a las
de los grandes gestores de bases de datos comerciales.
PostgreSQL utiliza un esquema cliente-servidor [8],
mediante el cul, para cada nueva conexin de un cliente
se genera un nuevo proceso servidor, que realiza las
funciones requeridas por el cliente. Cada servidor
dispone de un rea de memoria dedicada utilizada para
procesar datos intermedios. Adems, todos los procesos
servidores estn conectados a un rea de memoria
compartida cuya integridad se controla mediante
semforos. Este rea de memoria compartida funciona a
modo de cache, de tal manera que en ella se almacenan
los datos que han sido accedidos con anterioridad por
alguno de los servidores. Todas las modificaciones sobre
la base de datos se realizan sobre dicho rea de
memoria. Para asegurar la durabilidad de los datos,
dichas modificaciones son transferidas a disco antes de
que puedan ser utilizadas por el resto de los servidores.
PostgreSQL no soporta paralelismo a nivel de
consulta, lo que no permite dividir la ejecucin de una
consulta entre varios procesadores. Debido a esta falta
de paralelismo, y para provocar la mayor carga posible
en los sistemas, durante el Throughput Test se ejecutar
un stream por procesador del sistema.
Para realizar este trabajo utilizaremos un factor de
escala de 0,1 lo que nos proporciona una base de datos
de 100 MB en crudo. Los 100 MB se convierten en
aproximadamente 500 MB cuando se incluye en un
esquema relacional, se generan ndices para agilizar las
consultas y se provee de mecanismos de seguridad
necesarios para recuperar posibles fallos y permitir el
Roll-Back de las transacciones.
En trabajos anteriores se comprob[9] que este tamao
de base de datos conserva la complejidad de las
interrelaciones con las que se idearon las
especificaciones y adems permite realizar toda la
ejecucin en memoria principal, lo que asla el resultado
de la ejecucin de las prestaciones de los dispositivos de
almacenamiento.
Aunque utilizar este factor de escala no concuerda con
las especificaciones del benchmark TPC-H, ya que ste
slo contempla factores de escala enteros lo
emplearemos porque deseamos centrar el anlisis en la
arquitectura del sistema. Utilizar un tamao de base de
datos que no permitiera su ejecucin completa en
memoria principal supondra permitir que se produjese
un cuello de botella en el sistema de E/S. Para evitar esta
situacin, y as poder localizar otros posibles cuellos de
botella, se podran haber utilizado modelos de disco
perfectos. El hecho de utilizar dichos modelos tambin
hara desaparecer el efecto provocado por la
actualizacin de los datos, por parte de las funciones de
refresco, en las tablas de la base de datos. Asimismo, se
perdera el efecto provocado por los mecanismos de
integridad y roll-back. La eliminacin de estos efectos
provocara un patrn de comportamiento radicalmente
distinto al observado en sistemas reales.
IV. EL ENTORNO DE SIMULACIN.
A. El simulador SimOS.
SimOS proporciona tres modelos de ejecucin basados
en arquitecturas MIPS [10]:
Embra.- Este es el modelo de ejecucin ms
rpido disponible en SimOS. Utiliza un sistema
de ejecucin directa que no simula el
procesador ni la memoria cache y que permite
preparar las cargas de trabajo e interactuar con
el sistema operativo en la mquina simulada.
Permite ejecutar aplicaciones con un tiempo de
ejecucin unas diez veces superior al sistema
real. Existe una variacin de este modelo que
proporciona un esquema de cache simple.
Mipsy.- Este modelo simula un procesador
segmentado como los procesadores R3000 y
R4000. Adems lleva a cabo una simulacin
detallada de la jerarqua de memoria,
proporcionando dos niveles de memoria cache
y un interfaz de creacin de nuevos modelos.
Permite la utilizacin de arquitecturas UMA y
NUMA de 1 a 32 procesadores completamente
configurables. El tiempo de ejecucin en este
modelo es centenares de veces superior al de la
ejecucin en un sistema real.
MXS.- Este modelo simula un procesador
superescalar como el R10000. Adems
proporciona el mismo modelo de jerarqua de
memoria que el procesador Mipsy. Este modelo
se encuentra incompleto ya que slo reconoce
el juego de instrucciones del R3000, lo que
limita su utilidad. El tiempo de ejecucin es
miles de veces superior al del sistema real.

Los tiempos relativos de ejecucin son para un nico
procesador, hay que tener en cuenta que al ser un
simulador secuencial, este slowdown se incrementa
cuando se simulan varios procesadores.
El sistema simulado por SimOS incluye una unidad de
gestin de memoria (MMU) completa, con manejo de
excepciones, de tal manera que la traduccin entre
direcciones fsicas y virtuales ocurre igual que en el
sistema real.
Adems de los procesadores y la jerarqua de
memoria, SimOS incluye modelos de disco duro
complejos y de latencia fija, adems de un modelo de
interfaz de ethernet. El modelo de disco detallado
incluye el modelado del interfaz SCSI y realiza las
transferencias, tanto desde, como hacia la memoria a
travs de DMA, provocando una interrupcin una vez
que se ha completado la transferencia.
El simulador permite la ejecucin de un sistema
operativo IRIX 6.4 con pequeas modificaciones en el
kernel. Aunque posibilita correr aplicaciones actuales,
no permite actualizar el sistema operativo con versiones
ms modernas. Otra limitacin del simulador es el
4 AMIGO, PUENTE Y GREGORIO: METODOLOGA DE SIMULACIN PARA CARGAS TRANSACCIONALES DSS.

repertorio de instrucciones utilizado. Se puede salvar
compilando las aplicaciones con repertorios de
instrucciones reducidos, siempre y cuando se disponga
de los cdigos fuente, o de binarios compatibles con
estos procesadores. Esta limitacin del repertorio de
instrucciones reduce (aunque no elimina) la posibilidad
de utilizar aplicaciones comerciales.
B. Descripcin de los sistemas computacionales.
En trabajos anteriores [9] se caracterizaron dos
sistemas computacionales utilizando el benchmark TPC-
H. A continuacin adjuntamos una breve descripcin de
los mismos:
Un sistema SGI PowerChallenge de
arquitectura de acceso uniforme a memoria
sobre un bus PowerPath 2 con 8 procesadores
MIPS R10000 a 196 MHz, 1 Gigabyte de
memoria principal, 2 Megabytes de cache
unificada de segundo nivel y 32+32 Kilobytes
de cache de primer nivel ejecutando un sistema
operativo IRIX 6.5.
Un sistema SGI Origin 3200 de arquitectura de
acceso no uniforme a memoria NUMAflex, con
2 nodos de 4 procesadores MIPS R12000 a
400MHZ y 2 Gigabytes de memoria principal
por nodo, 8 Megabytes de cache unificada de
segundo nivel y 32+32 Kilobytes de cache de
primer nivel ejecutando un sistema operativo
IRIX 6.5.
Estos dos sistemas pueden ser introducidos en el
entorno de simulacin con lo que, una vez verificada la
estacionaridad de los sistemas reales, se puede realizar la
simulacin de ambas arquitecturas.
V. METODOLOGA DE ESTUDIO.
A. Consideraciones acerca del entorno de simulacin
La velocidad de ejecucin de un sistema de ocho
procesadores en el entorno simulado, es de
aproximadamente 1,8x10
5
instrucciones por segundo en
modo Mipsy. Si tenemos en cuenta que la ejecucin
completa del benchmark requiere la ejecucin de
aproximadamente 1,5x10
12
instrucciones, seran
necesarios unos 100 das para completar la simulacin.
Si se utilizase un modo MXS seran necesarios unos tres
aos para completar la simulacin.
Esta limitacin temporal obliga a desarrollar una
metodologa de simulacin que permita el estudio de
posibles mejoras arquitectnicas en un plazo de tiempo
razonable.
Como se ha comentado anteriormente, la variacin del
tamao de la aplicacin provoca un patrn de
comportamiento diferente, al variar los mtodos
seleccionados para resolver las consultas, el uso de
ndices, y sobre todo el nmero de relaciones cruzadas
entre las distintas tablas de la base de datos. Esto obliga
a ejecutar en el simulador la misma carga de trabajo que
se ha demostrado efectiva en el sistema real.
Al no poder escalar la carga de trabajo como se realiza
en cargas numricas, estudiaremos la posibilidad de
realizar un escalado temporal. Para ello, emplearemos la
capacidad de Checkpoint y Restart que proporciona el
simulador. Mediante esta funcionalidad es posible
comenzar una ejecucin con un modelo de procesador
simple para, posteriormente, cambiar el modo de
ejecucin a un modelo ms detallado.
Para realizar un Checkpoint es necesario situar un
punto de parada que puede venir fijado por un nmero
de ciclos determinado, la llegada a un punto del cdigo
predeterminado, o cuando se obtenga una respuesta por
consola. No obstante, para utilizar un Checkpoint,
SimOS no permite que haya ninguna instruccin de salto
evalundose en ninguno de los procesadores del sistema.
Esta limitacin a la hora de situar los Checkpoints puede
predeterminar el punto en el que se deba cambiar de
modo de ejecucin, como veremos ms adelante.
El escalado temporal ha de ser realizado de tal manera
que permita asegurar que el punto de trabajo del sistema
es el mismo que el del sistema real. Esto permitir
estudiar el efecto de posibles mejoras en el rendimiento
del sistema.
Como PostgreSQL no permite paralelismo a nivel de
consulta, y al estar nuestro trabajo dedicado al estudio
de arquitecturas multiprocesador, enfocaremos la
simulacin en el Throughput Test. Este enfoque permite
que la ejecucin del Power Test pueda ser realizada en
un modo de ejecucin poco detallado, lo que nos
permite reducir el tiempo de simulacin. An as, la
ejecucin restante supone un tiempo de simulacin
prohibitivo (60 das). Un tiempo de ejecucin tan
elevado nos obliga a reducir an ms la zona de la
ejecucin que se simular.
El patrn de ejecucin del Throughput Test muestra
una zona de transitorios al inicio de la ejecucin. Dichos
transitorios se deben al establecimiento de las
conexiones. Tambin presenta una segunda zona
transitoria en su conclusin debido a la finalizacin de
las mismas y almacenamiento de los resultados. Durante
el resto de la ejecucin el patrn de comportamiento es
relativamente estacionario.
B. Determinacin de la estacionaridad
A continuacin mostraremos el comportamiento de la
carga de trabajo a lo largo de su ejecucin. Lgicamente
estas medidas no pueden ser llevadas a cabo en el
entorno simulado por que necesitamos conocer el
resultado de la ejecucin completa del benchmark.
Como hemos comentado previamente es nicamente
factible en el entorno real. Analizaremos diferentes
porciones de la ejecucin y comprobaremos cul es la
desviacin de los parmetros ms significativos del
sistema con respecto a la media final observada.
En este anlisis nos centraremos exclusivamente en las
tasas de acierto de las caches y el nmero de
instrucciones por ciclo. Por tanto, compararemos estas
cantidades durante el total de la ejecucin y en
intervalos de tiempo menores.
Para obtener estos datos se recurrir al sistema real
empleando los contadores hardware que proporcionan
los procesadores MIPS R10000/R12000. Utilizando una
librera externa enlazada en tiempo de ejecucin, se
pueden obtener los valores de estos contadores mediante
muestreos temporales. Estos muestreos provocan una
perturbacin escasa en la ejecucin (inferior al 3%).
XIV JORNADAS DE PARALELISMOLEGANES, SEPTIEMBRE 2003 5
Para comprobar la estacionaridad de la ejecucin
estudiaremos el Throughput Test desde el comienzo de
su ejecucin. Tendremos que tener en cuenta, que el
punto ms seguro para colocar un Checkpoint dentro del
simulador es precisamente el punto en el que finaliza el
Power Test y comienza el Throughput Test. El comenzar
la ejecucin simulada, en modo detallado, en este punto
incorpora en la medida el efecto transitorio del
establecimiento de las conexiones y los fallos de
arranque en fro. As, en la figura 1 se muestra el error
cometido al aproximar la tasa de acierto de la cache de
datos de primer nivel mediante un intervalo de tiempo,
frente al promedio de dicho test al completo. Tambin se
muestra el porcentaje del tiempo de ejecucin que
representa dicha medida sobre el total del Throughput
Test.

Error entasadeaciertoencachededatosL1
0,00%
5,00%
10,00%
15,00%
20,00%
25,00%
30,00%
35,00%
1seg 5seg 10seg 20seg 30seg 40seg 50seg 1min 2min 3min 4min
Error %Throughput Test

Fig. 1.- Error cometido al aproximar la tasa de fallos de la cache de
datos de nivel uno en un intervalo inferior a la ejecucin completa.

Como se puede observar, la tasa de acierto en la cache
de datos de primer nivel presenta un comportamiento
estacionario. A partir de 10 segundos de ejecucin el
error cometido es inferior al 5%. A partir de 2 minutos,
y hasta el final de la ejecucin este error es inferior al
1%. Una desviacin del 1% se puede producir entre dos
ejecuciones sucesivas en el mismo sistema. Debido a
esto, a partir de los 2 minutos de ejecucin se puede
considerar despreciable el error cometido al aproximar
la tasa de acierto de la ejecucin por la tasa de acierto
del intervalo. Con este resultado podemos decir que el
comportamiento de la jerarqua de memoria durante la
ejecucin de la aplicacin puede ser caracterizado
mediante la simulacin de 10 segundos con un error
inferior al 5%. Si el tiempo de simulacin se amplia a
los dos minutos podemos caracterizar e comportamiento
de la jerarqua con un error prcticamente despreciable.
La segunda medida obtenida sobre la regularidad del
sistema ha sido la cuenta de instrucciones por ciclo por
procesador. El error cometido al aproximar la tasa media
de la ejecucin por el valor obtenido en diferentes
intervalos, as como el porcentaje de ejecucin del
Throughput Test que representan dichos intervalos, se
muestra en la figura 2.
Error enInstrucciones/ciclo
0,00%
5,00%
10,00%
15,00%
20,00%
25,00%
30,00%
35,00%
40,00%
45,00%
50,00%
1seg 5seg 10seg 20seg 30seg 40seg 50seg 1min 2min 3min 4min
error %Throughput Test

Fig. 2.- Error al considerar la cuenta de instrucciones por ciclo en un
intervalo inferior a la ejecucin completa.

Como se puede observar, para intervalos muy cortos,
se produce un error considerable, pero a partir de 20
segundos de ejecucin el error cometido es inferior al
5%. Es conveniente destacar, aunque no se muestre en la
figura por no ser relevante, que este error se mantiene
siempre inferior al 5% a partir de 20 segundos, sin
importar el tamao del intervalo.
La cuenta de instrucciones por ciclo es un reflejo de
todo lo que ocurre en el sistema, ya que cualquier
variacin en las tasas de las caches, los predictores de
salto, TLB o bloqueos se refleja en ella. El hecho de que
presente un comportamiento estacionario es un reflejo
de la estacionaridad del sistema. Dicho comportamiento
permite, ejecutando una parte de la simulacin, obtener
el impacto relativo de cualquier mejora arquitectnica
con esta carga de trabajo.
VI. CONCLUSIONES.
El uso extensivo de cargas de trabajo transaccionales
en un elevado porcentaje de los computadores de altas
prestaciones hace necesaria su inclusin en el marco de
trabajo empleado a la hora de validar la efectividad de
nuevas alternativas arquitectnicas en este contexto.
Puesto que la metodologa de diseo pasa
ineludiblemente por el empleo de herramientas de
simulacin y dado el elevado tiempo de computacin
necesario para ejecutar cargas transaccionales
complejas, se necesita reducir sus exigencias
computacionales.
En este trabajo hemos puesto de manifiesto la
estacionaridad de la ejecucin de un benchmark TPC-H
sobre una base de datos creada en PostgreSQL.
Utilizando esta estacionaridad es posible realizar
ejecuciones de 20 segundos de tiempo simulado para
caracterizar el correcto funcionamiento de dichas
mejoras. Estas simulaciones suponen, utilizando
procesadores MIPS R12000 a 400 MHZ, un tiempo de
simulacin de unas 36 horas para un sistema de 8
procesadores. La etapa de posicionamiento permite tener
lista la carga de trabajo en un tiempo inferior a tres horas
para un sistema de 8 procesadores. Esta carga de trabajo,
mediante el uso de checkpoints, slo ha de ser preparada
6 AMIGO, PUENTE Y GREGORIO: METODOLOGA DE SIMULACIN PARA CARGAS TRANSACCIONALES DSS.

una vez, ya que puede ser reutilizada en sucesivas
simulaciones.
Esto nos permite obtener un error inferior al 5%
ejecutando el 3% del Throughput Test. El total de la
simulacin supone un tiempo de computacin inferior a
dos das para un sistema de 8 procesadores, frente a los
ms de 100 das requeridos en principio para realizar la
simulacin de la aplicacin.
VII. AGRADECIMIENTOS
Los autores quieren expresar su ms sincero
agradecimiento a William Hachfeld de SGI por su
inestimable ayuda en el desarrollo de las libreras que
han permitido muestrear los contadores hardware de los
procesadores R10000/R12000.
VIII. REFERENCIAS.
[1] http://www.top500.org.
[2] http://www.tpc.org.
[3] David E. Culler, Jaswinder Pal Singh Parallel Computer
Architecture. 1999 Morgan Kaufmann Publishers, Inc.
[4] L. A. Barroso, K. Gharachorloo, and E. D. Bugnion. Memory
System Characterization of Commercial Workloads. In
Proceedings of the 25th International Symposium on Computer
Architecture, June 1998.
[5] M. Rosenblun, E. Bugnion, S. Devine, and S. A. Herrod.
Using the SimOS machine simulator to study complex computer
systems. ACM Transactions on Modeling and Computer
Simulation, Vol. 7, No. 1, January 1997, Pages 78103.
[6] TPC Benchmark H (Decission Support) Standard
Specification Rev. 1.3.0 1993 2002 Transaction Processing
Performance Council.
[7] http://www.postgresql.org
[8] PostgreSQL Developer Version of the Docs. Internal
Architecture.
[9] L. Amigo, V. Puente, J.A. Gregorio, Demanda computacional
del benchmark TPC-H. XIII Jornadas de paralelismo Lleida.
[10] S. Herrod y COL , The SimOS simulation enviroment.
1996 Standford University.