Diapositiva 1

1
Centro Nacional de Supercomputación
Analyzing LoadLeveler historical information for
performanceprediction
Francesc Guim Bernat Julita Corbalán CorbalánJesús
Labarta
Barcelona, Date 2005
2
Agenda

• Introducción
• Motivaciones y objetivos
• Arquitectura eNanos
• El workload
• Punto de partida
• El sistema y el workload
• Análisis del workload
• Las aplicaciones
• El usuario
• Conclusiones

3
Introducción

• Motivaciones
• Arquitectura

4
Motivaciones y objetivos

• En sistemas HPC y sistemas grid orientados a la
  HPC
• la predicción ? puede incrementar su eficacia y
  facilitar la vida de nuestros usuarios.
• Nosotros queremos aplicar la predicción a
• Planificación de tareas a dos niveles
• A nivel de grid ? Con políticas de brokering
  basadas en predicción (p.e con políticas basadas
  en el economic grid)
• A nivel local ? Con modelos de scheduling basados
  en estimaciones.
• Ayudar al usuario.
• Respondiendo a preguntas como
• Como se ejecutará la tarea X si la lanzo en el
  centro Y con los recursos R1,, Rn ?
• Cual será el estado futuro del sistema en el
  momento T ?
• Cuanto le falta a mi tarea X para finalizar su
  trabajo ?
• Que recursos necesito para cumplir mi deadline
  para mi tarea X ?

5
Motivaciones y objetivos

• No obstante, en el contexto en que trabajamos
  aparecen muchos elementos nuevos a modelar
• Brokers
• Organizaciones Virtuales (VOs)
• Protocolos de negociación
• Políticas de planificación distintas.
• Recursos distintos
• Políticas de asignación de recursos
  extremadamente variables
• Como se lanzan las tareas
• Stagein y stageout de ficheros
• Laténcias muy variables
• Dependencias entre tareas, y dependencias entre
  datos.
• Etc.

6
Motivaciones y objetivos

• Se nos plantean algunas cuestiones como
• Como podemos aplicar la predicción en sistemas de
  planificación con recursos heterogéneos ? (grids,
  cluster con nodos heterogéneos etc.)
• En sistemas grid aparecen temas como las
  complejas VOs (organizaciones virtuales)
• Distintas políticas, distintos recursos,
  distintas políticas locales, distintos
  planificadores etc.
• Como podemos utilizar información que proviene de
  distintos niveles para afinar más nuestras
  predicciones ? (nivel grid y nivel local).
• Que inputs necesitan los predictores ? De donde
  podemos extraer dichos inputs ?

Como los evaluamos ?
Cuales son significativos ?
Que pueden facilitar los brokers ?
Como los vinculamos ?
Como los filtramos ?
Y los sistemas locales ?
7
Arquitectura eNanos

• Todos estos objetivos se enmarcan en un proyecto
  bastante amplio. La arquitectura eNanos

• Donde el sistema de predicción
• Facilita predicciones al eNanos Broker y al
  eNanos Scheduler.
• Obtiene información de nivel grid y nivel local
  ya vinculada del Information System.
• Donde los eNanos Broker y Scheduler
• Pueden utilizar técnicas de planificación
  basadas en dichas estimaciones.
• Deben hacer feedback del resultado de las
  predicciones al sistema de predicción.

8
El workload

• Punto de partida
• El sistema
• Generación del workload

9
Punto de partida

• Muchos caminos a investigar !!! y muy complejos
  !!!
• Buscamos un punto de partida más sencillo
• Para acotar los distintos factores que influyen
  predicción
• Guiarnos en el proceso de diseñar técnicas de
  predicción

Partir con tantas variables a la vez es
intratable !
Mr. Predicción
Nosotros
Los usuarios
Que información podíamos extraer del workload de
nuestro sistema ?
Estudiar
Punto de partida

Sus trabajos
10
El sistema

• Decidimos comenzar nuestro estudio en dos de
  nuestros sistemas
• Kadesh, una computadora IBM RS-6000 SP con la
  siguiente configuración
• 8 Nodos de 16 Nighthawk Power3 _at_375Mhz (192
  Gflops/s), con 64 Gb RAM. Y 9 nodos de 4 IBM p630
  p630 Power4 _at_1Ghz (144 Gflops/s) with 18 Gb RAM.
  
• A total of 336Gflops y 1.8TB disco duro. Todos
  los nodos conectados con un SP Switch2 de
  velocidad at 500MB/sec. AIX
• Gestor de colas Load Leveler y Sistema operativo
  AIX.
• Marenostrum, una computadora IBM con la siguiente
  configuración
• 42.35 Teraflops de rendimiento de pico teórico
• 4.812 procesadores PowerPC 970FX en 2400 Nodos
  duales
• 9.6 TB de memoria y 236 TB de almacenamiento en
  disco
• 3 redes de interconexión Myrinet, Gigabit
  Ethernet y Ethernet 10/100

11
El workload

• Inicialmente estudiamos el workload de Kadesh
• Disponíamos una histórico binario de Load Leveler
  de los últimos tres años de nuestro sistema.
• A través de la LoadLeveler API podemos acceder a
  campos de la traza sobre
• Las características del computador y su estado.
• Las características estáticas y dinámicas de cada
  uno de los trabajos.
• En LoadLeveler se modelan los trabajos a través
  de jobs y steps, donde podemos tener cosas como

job
job
Varios steps por job (no usado por nuestros
usuarios)
El modelo más común
step
step
step
step

tasks
tasks
tasks
tasks
tasks
tasks
12
El workload

• A partir de los históricos binarios del LL
• Generamos una traza en formato ASCI para poder
  estudiar los trabajos.
• A través de la librería LLAPI de Load Leveler
• Cuyo formato estaba basada en el Standard
  Workload Format de D. Feitelson
• Nombre del trabajo
• Grupo y nombre del usuario
• Segmento de datos y tamaño de pila
• Numero de cambios de contextos voluntarios e
  involuntarios
• Estado del trabajo
• Numero de Tasks
• Tiempo total, Tiempo de sistema y tiempo total.
• Memoria.

Job
Campos que no pertenecen al estándar, pero pueden
dar información útil.
Step
13
El workload

• El proceso de generación de la traza

Trazas binaria cada traza pertenece a un
periodo de tiempo
Traza final
Procesado de cada traza en bloques de k bloques
gtgt
Bin X
ll_set_request(fechas) ll_get_objs ll_get_object
Proceso de filtrado
job
LLAPI
job
job
SWF
job
ll_get_data(job,Campo)
ll_get_data(job, LL_JobGetNextStep)
step
ll_get_data(step,Campo)
ll_get_data(task, LL_StepGetMasterTask)
14
El workload

• Problemas aparecidos con el trabajo de la
  librería
• Segmentation faults causados al procesar
  algunas trazas binarias grandes
• Adaptarse en estos casos y hacer las consultas de
  fechas de tiempo más cortos.
• Muchos de los campos a veces no tiene valor
• Porqué el sistema no los soporta.
• Porqué el usuario no los especificó en script de
  LoadLeveler. P.e LL_StepOutputFile
• Ojo ! A veces no los escribe pero LL los rellena
  con valores no muy fiables. Pe LL_TaskExecutable
  
• A veces campos con valores lt 0
• Las entradas del workload con valores
  incoherentes han sido filtrados.
• No podemos identificar la aplicación de forma
  precisa (ejecutable ?, LL script ? ? parece que
  no)

15
El workload

• El campo ejecutable de la traza normalmente era
  el nombre del script de LL.
• Muy difícil, por no decir imposible, determinar
  un identificador de aplicación.
• Dependía de cómo el usuario ha creado dicho shell
  !
• Frecuentemente encontramos cosas como
• 1704.job ? donde no se puede intuir nada.
• radix.4,radix.8, radix.16 ? podríamos
  intuir que se executa la aplicación radix con
  distintas configuraciones (numero cpus?)
• radix.a ? podríamos intuir que se lanza la
  aplicación a
• sp2n1.47383 ? donde LL ha asignado el nombre al
  script de forma automática. No podemos intuir
  nada.
• Problemas sobre el ejecutable / aplicación
• En un porcentaje elevadísimo de casos solo
  podemos intuir
• En muchos otros caso no podemos saber nada.

Como hacer intuir a un predictor ? Técnicas
complejas !
16
El workload

• Punto de partida
• El sistema
• Generación del workload

17
Las aplicaciones

• Un primer análisis nos muestra que
• Las aplicaciones paralelas han consumido un x10
  veces más de recursos que las secuenciales !
• Dispersión de tiempo usuario y sistema
• Nos sugiere encontrar grupos de trabajos para
  disminuirla
• Las aplicaciones paralelas tienen tiempos muy
  variables.
• No se pueden establecer de forma clara ni
  patrones ni relaciones entre variables.

Búsqueda de normalidad !
18
Las aplicaciones

• Acceso a los datos
• Las trazas no contiene información relativa a
• Operaciones I/O, Trafico de red, ficheros de
  entrada / salida
• Se ha intentado extrapolar a grandes rasgos a
  través de variables como
• Fallos de página, cambios de contexto, segmento
  de datos
• En general aplicaciones paralelas lanzadas usaron
  72 veces más de memoria que las secuenciales
• Explica el tiempo de sistema es también 10x ?
• Cambios de contexto 21 veces más grandes que en
  las paralelas
• El IQR y dispersión del tiempo de sistema es alta
  al igual que
• El IQR y dispersión de segmento de datos,
  falladas de pagina etc.
• corr(Tsistema, Datasegment) 0.47
• corr(Tsistema, Falladas de páginas) 0.45

Los datos han de ser normales !!
Quizá existe alguna relación
19
Las aplicaciones

• Efectos colaterales !
• La dispersión o variabilidad del tiempo de
  sistema puede venir dada por
• Los datos
• El estado del sistema
• Otros factores
• Hay que
• Establecer relaciones entre este tipo de
  variables. (Buscar variables respuesta y
  explicativas)
• Buscar patrones o modelos.
• Necesitamos más variables ! Que nos ayuden a
  encontrar la normalidad !

• Factor de carga alto
• Muchos paquetes de red. Etc.

• Factor de carga bajo
• Nodo/s exclusivo para un solo job.
• Poco tráfico de red. Etc.

• Franja horaria

• Época del año

20
Las aplicaciones

• El nivel de paralelismo de las aplicaciones es
  bastante variable
• Puede ser una buena variable discriminatoria.
• No obstante, iguales aplicaciones se ejecutan
  pocas veces con el mismo Tasks
• En estudios según Tasks y aplicaciones no
  podremos usar según que estadísticos ! (Pocas
  muestras)
• Hay que buscar variables que nos ayuden a
  identificar modelos de programación
• MPI ?
• MPI Open MP ?
• Secuencial ?
• De todos modos con las trazas actuales no podemos
  determinar con exactitud que son las aplicaciones

21
Los usuarios y grupos

• Los usuarios acostumbran a lanzar una misma
  aplicación
• En mediana 9 veces
• En media 82 veces
• Los grupos de usuarios acostumbran a lanzar una
  misma aplicación
• En mediana 195 veces
• En media 1779 !
• En las siguientes etapas deberíamos realizar un
  estudio más a fondo de los usuarios y sus
  comportamientos.

Un buen inicio puede ser buscar relaciones
discriminando según grupos y usuarios !

• Tiene sentido usar técnicas de predicción con
  estas entradas
• Usuario
• Grupo

22
Conclusiones

• Para poder establecer relaciones claras y fiables
  entre variables del workload
• Es imprescindible buscar la normalidad de estas.
• No obstante con la información actual no la hemos
  podido encontrar. Necesitaríamos
• Para predecir tiempos de sistema asociado a un
  aplicación necesitamos recolectar
• Variables que nos indiquen la actividad de IO de
  esta

día
festivo
hora
época del año
tamaño
Ficheros entrada
hash
Input ops
Trafico de red
Actividad de disco
Output ops
tamaño
Ficheros salida
hash
23
Conclusiones

• Variables que nos indiquen el estado del sistema
  cuando se lanzó la aplicación
• Necesitamos identificar de forma más precisa que
  aplicaciones lanza un job
• Lista ejecutables
• Número de tasks y threads
• Tener acceso al script de Load Leveler lanzado
  para ejecutar el job ?

nº jobs
Actividad disco
Load factor
Actividad de red
set base_dir "/user1/uni/upc/ac/fguim/AlgoPar
s/radix_source_parallel" set version
"radix" setenv OMP_NUM_THREADS 16 set procs
32 while ( input_value lt max_value )
base_dir/bin/radix_ar_2001_NoOMP
input_value procsgtgt base_dir/results/res_
192M.txt _at_ input_value input_value
increment end
24

• Gracias !