PowerMaster y su relación con
la ejecución de un trabajocola32La ejecución de programas de cálculo por los usuario se lleva a cabo a través
del sistema de colas, para que éste determine cómo y dónde se ejecuta. En la
actualidad, todos los sistemas de Cluster de Modelización emplean el
sistema de colas torque 2.3.6
combinado con el scheduler
Maui 3.2.6p21.
La última reordenación del clúster ha tenido como principal consecuencia la unificación del sistema de colas, que es ahora común a todo el clúster. Así, la cola escogida por el usuario selecciona el subclúster adecuado.
Cada uno de los tres subclústeres de ordenadores
(cmi, cmq, cmd) pueden encontrarse en uno de estos dos modos:
Las características de las colas actuales del clúster de modelización se resumen en la siguiente tabla:
cola32 | cola8 |
cola8_cmq |
cola2 |
|
|---|---|---|---|---|
| Subclúster | cmi | cmi |
cmq | cmd |
| Número máximo de trabajos ejecutándose simultáneamente | 4 | 16 | 10 | 40 |
| Número máximo de cores disponibles para un trabajo | 32 | 8 | 8 | 2 |
| Número máximo de nodos a utilizar por un trabajo | 4 | 1 | 1 | 1 |
| Límite máximo de memoria virtual para un trabajo | 32Gb (por nodo) | 32Gb | 16Gb | 4Gb |
| Tamaño máximo de fichero temporal en un trabajo | 220 Gb (por nodo) | 220Gb | 200Gb | 180Gb |
| Límite de tiempo de reloj a consumir por un trabajo (horas) | 96:00:00 | 96:00:00 | 96:00:00 | 120:00:00 |
| Número máximo de trabajos a ejecutar por un usuario | 1 | 4 | 2 | 8 |
| Tipo de trabajo más adecuado | MPI | OpenMP | OpenMP | Serial, distribuido, interactivo |
Nota: Las características de las colas de producción podrán modificarse en función de la evolución observada en la carga global del sistema y de las preferencias de uso de los usuarios.
El orden de prioridad de los trabajos en una cola se establece por el
scheduler Maui aplicando una política fairshare que
tiene en cuenta varios factores, siendo el criterio de mayor
peso el tiempo de ejecución demandado. Cuanto menor tiempo de ejecución
solicitado, en general mayor prioridad. Se considera igualmente el uso que el
grupo ha hecho de la CPU durante la semana anterior, de manera que se priorizarán
los trabajos de los grupos que no hayan hecho mucho uso de CPU durante ese
periodo.
Los trabajos se definen en un script que contiene las variables y
comandos a ejecutar en el trabajo. Todos los envíos de trabajos a colas deben
hacerse desde la línea de comandos de cualquiera de los servidores de entrada
mediante comandos particularizados para cada tipo de cola (cola32,
cola8, cola2,...).
Por ejemplo:
usuario@jaula04:> cola32 trabajo.sh
envía a la cola32 que se ejecuta en los nodos de
cálculo del subclúster cmi el trabajo definido en el
siguiente script:
#!/bin/bash #PBS -l walltime=00:05:00 #PBS -m e #PBS -M usuario@uniovi.es # Se requiere un tiempo maximo de 5 min # Al finalizar el trabajo se envia un e-mail al usuario (opcional) echo "Hello, batch system!"
Como se ve en este ejemplo, los scripts contienen comandos de
shelly pueden pasar más parámetros de ejecución al sistema de colas
según la sintaxis mostrada en las líneas encabezadas por #PBS.
En el ejemplo, se solicitan 5 min. de tiempo de ejecución y se envía un
e-mail al usuario a la finalización del trabajo.
Alternativamente, los parámetros de ejecución en colas pueden pasarse
como opciones a los comandos cola32,
cola8, cola2,... en la misma línea de comandos como sigue:
usuario@jaula04:> cola32 -l walltime=00:05:00 trabajo.sh
Por supuesto, es posible múltiples parámetros de ejecución que controlan
otros recursos. Consúltense las páginas de manual del comando
qsub de Torque para más información.
Una vez ejecutado el trabajo, el sistema de colas devuelve dos ficheros que
contienen la salida estándar producida por el trabajo y un fichero de errores
de ejecución. Por defecto estos ficheros tienen el mismo nombre que el
script enviado al sistema de colas, pero con una extensión
añadida. En el anterior ejemplo, el fichero de output estándar es:
*** Job 3.jaula04.sct.uo started on mother: at Wed Apr 1 18:49:37 CEST 2009 *** Local directory /scratch/3.jaula04.sct.uo in yei13 created *** Flush cache memory in yei13 *** Local directory /scratch/3.jaula04.sct.uo in yei14 created *** Flush cache memory in yei14 *** Local directory /scratch/3.jaula04.sct.uo in yei15 created *** Flush cache memory in yei15 *** Local directory /scratch/3.jaula04.sct.uo in yei16 created *** Flush cache memory in yei16 *** Do not forget to move relevant information to /home destination *** Local directory is deleted after job completion ------------------------------------------------------------------- Hello, batch system! ------------------------------------------------------------------ *** Job completed Wed Apr 1 18:50:13 CEST 2009 *** Local directory /scratch/3.jaula04.sct.uo in yei13 deleted *** Local directory /scratch/3.jaula04.sct.uo in yei14 deleted *** Local directory /scratch/3.jaula04.sct.uo in yei15 deleted *** Local directory /scratch/3.jaula04.sct.uo in yei16 deleted -------------------------------------------------------------------
En este fichero se informa del inicio y fin de la ejecución, y de la
creación de dos subdirectorios temporales en los directorios
/scratch de los dos nodos de cálculo reservados por el trabajo.
Se informa, demás, del vaciado previo de la memoria cache en cada nodo,
operación que consume alrededor de 30 s en los nodos con mucha
memoria RAM. Una vez finalizado el trabajo, el gestor de colas borra
automáticamente el directorio temporal para dejar el espacio
/scratch libre para los siguientes trabajos.
El sistema de colas define automáticamente la variable $SCRATCH
para que los usuarios copien o muevan ficheros desde el directorio de trabajo
(en el que se lanzó el trabajo) al directorio temporal. Para los trabajos en
cola32 que utilizan 4 nodos se definen igualmente las variables
$SCRATCH1, $SCRATCH2,… que apuntan a los directorios
temporales de cada nodo reservado para el trabajo. Estos directorios son
accesibles entre los distintos nodos reservados al trabajo mediante
exportación NFS automática. Es muy importante que los usuarios aprovechen el
espacio definido en el directorio $SCRATCH. Cualquier
trabajo que requiera entrada/salida masiva de datos a disco duro debe
prepararse para mover adecuadamente los datos como se muestra en el siguiente
ejemplo de script de ejecución:
#!/bin/bash # Copia los datos situados en el directorio # desde el que se envio el trabajo al directorio # de trabajo temporal cp $PBS_O_WORKDIR/data.1 $SCRATCH/ # Se procesan los datos en el $SCRATCH cd $SCRATCH /home/usuario/myprogram.exe < data.1 > output.1 # Se finalmente transfieren los datos generados cp output.1 $PBS_O_WORKDIR/
Si el espacio del directorio temporal es insuficiente, se recomienda
alternativamente emplear las particiones de datos
/msa. En cualquier caso, por
favor, consúltese con el técnico
del sistema cualquier duda sobre el movimiento y la localización de datos.
PowerMaster y su relación con la ejecución de un trabajoEl trabajo que un usuario envía es controlado por el sistema de colas; el
scheduler Maui se encarga de determinar cuando y dónde
se ejecuta el trabajo requerido por el usuario en función del grupo del mismo,
del tiempo requerido y del tiempo de proceso consumido duranto los últimos
días.
Con el objetivo de ahorrar energía consumida por nodos inactivos, la Unidad
ha desarrollado un sistema (PowerMaster) que interacciona con el
sistema de colas y apaga nodos de cálculo que no vayan a ser utilizados y los
inicia cuando detecta que hay trabajos que necesitan nodos para ser ejecutados.
Por ello, es posible que el usuario pueda observar que un trabajo que esperare
se ejecutase inmediatamente, pueda retrasarse varios minutos debido a que el
sistema se encuentre iniciando los nodos necesarios para el mismo.
En la actualidad, este sistema sólo está operando en las colas
cola2 y cola8_cmq.
Si compilamos con pgf95 un
programa FORTRAN que contenga bucles, podemos generar un ejecutable capaz de
aprovechar varios procesadores en memoria compartida:
pgf95 myprogram.f –O2 –Mconcur –o myprogram
La variable de entorno $NCPUS determina el número de núcleos
de proceso a utilizar en el momento de la ejecución. Un posible script
a enviar con el comando cola8 anteriormente mencionado, sería:
#!/bin/bash # Encuentra el numero de procesadores para la ejecucion OpenMP NCPUS=`wc -l < $PBS_NODEFILE` export NCPUS echo Este trabajo usa $NCPUS procesadores ./myprogram < input.file > output.file
En este ejemplo se ha hecho uso de la variable de entorno del sistema colas
$PBS_NODEFILE para determinar el número de procesadores
disponibles por el programa.
Los ejemplos equivalentes con el compilador
ifort (disponible tanto en
cmq como cmd) son:
ifort myprogram.f -O2 -parallel -o myprogram
Siendo el script para ejecución en colas:
#!/bin/bash # Encuentra el numero de procesadores para la ejecucion OpenMP OMP_NUM_THREADS=`wc -l < $PBS_NODEFILE` export OMP_NUM_THREADS ./myprogram < input.file > output.file
La variable de entorno $OMP_NUM_THREADS
determina el número de procesadores a utilizar en el momento de la ejecución.
cola32 El nuevo clúster CMI dispone de las librerías de cálculo paralelo
HP-MPI en
su versión 2.1. Estas librerías reconocen los estándares MPI-1 y MPI-2 y
hacen uso de la interconexión Infiniband de altas prestaciones disponible en los
nodos de cálculo de CMI. Las librerías HP-MPI sólo están por tanto accesibles en
el clúster cmi. Si se dispone de un programa (myprogram_mpi) compilado con la librería
HP-MPI , la ejecución en colas debe hacerse
con un script del siguiente tipo incluyendo una llamada al comando
mpirun:
#!/bin/bash mpirun ./myprogram_mpi <argumentos>
En los nodos de cálculo, la ejecución bajo el sistema de colas del comando
-v -IBV -prot -hostfile $PBS_NODEFILE -np $NPROCS
de modo que se selecciona la red Infiniband de calculo (-IBV),
se vuelca información sobre la ejecución del programa (opciones
-v y -prot) y se seleccionan el número de procesos
y los nodos para el cálculo paralelo que proporciona el sistema de colas
torque (opciones -hostfile y -np). No obstante, se
recomienda a todos los usuarios consultar las páginas de manual del comando
mpirun donde encontrarán muchas otras opciones de ejecución que
pueden ser de interés para optimizar la ejecución de sus trabajos. En
particular, la opción:
-intra=shm|nic|mix
permite escoger el método de comunicación intranodo entre memoria
compartida (shm; que se espera tenga la menor latencia), o a
través de la tarjeta de red Infniband (nic), o un método mixto
(mix) que consiste en utilizar la red para mensajes de gran
tamaño y la memoria compartida para mensajes cortos. Otra opción interesante
de comando mpirun de HP-MPI nos permite enlazar los
procesos de un trabajo MPI a núcleos de proceso determinados dentro de cada
nodo, lo que puede mejorar el rendimiento en acceso a memoria RAM y
comunicación entre procesos intranodo. Por ejemplo, con la siguiente opción:
-cpu_bind=v,cycle,v
se distribuyen cíclicamente los 8 procesos (hilos) intranodo entre los núcleos de los 2 procesadores (thread 1 ® núcleo 1 - proc 1; thread 2 ® núcleo 1 - proc 2; thread 3 ® núcleo 2 - proc 1; ...). Consúltese las páginas de manual de mpirun para ver más posibilidades de la opción -cpu_bind.
cola8, cola2Si se dispone de un programa (myprogram_mpi) compilado con la
librería Intel-MPI configurada por defecto
en los nodos de cálculo, la ejecución en colas debe hacerse con un
script del siguiente tipo incluyendo una llamada al comando
mpiexec:
#!/bin/bash mpiexec -comm=mpich2-pmi ./myprogram_mpi <argumentos>
El comando mpiexec reemplaza a mpirun para la
ejecución de trabajos MPI en los subclústeres cmq y
cmd. Es muy importante usar siempre mpiexec en este
tipo de trabajos MPI para la correcta finalización o detención de los mismos.
Asimismo, y dado que la librería Intel-MPI emplea el estándar MPI-2, en el
ejemplo se especifica este protocolo de comunicación con la opción
-comm=mpich2-pmi. Si se desea ejecutar un programa
MPI compilado con otra librería bajo estándar MPI-1, entonces la opción
correspondiente sería -comm=mpich-p4.
Más información sobre mpiexec está disponible en las páginas
de manual.
NOTA: Los tres subclústeres disponen de otras librerías para cálculo paralelo: MPICH1.2, MPICH2 y OpenMPI. Consúltese con el técnico del sistema cualquier duda sobre el envío de trabajos de programas compilados con estas librerías.
Si se desea ejecutar al mismo tiempo N
programas o tareas en serie (por ejemplo N=8 en cola8, ...), entonces es posible enviar un trabajo distribuido haciendo uso del comando mpiexec con las opciones que se
ejemplifican en el siguiente script :
#!/bin/bash mpiexec -comm=none -conf distribution.txt
de este modo, el sistema de colas ejecutará los trabajos definidos en el
fichero de distribution.txt y que no requieren intercomunicación (-comm=none) al tratarse de trabajos en serie. La sintaxis del
fichero distribution.txt es muy sencilla; cada línea asigna el
número de procesadores y la ruta al programa o tarea correspondiente:
# Ejemplo de fichero para distribuir tareas -n 1 : ./my_task_1.sh -n 1 : ./my_task_2.sh -n 1 : ./my_task_3.sh -n 1 : ./my_task_4.sh -n 1 : ./my_task_5.sh -n 1 : ./my_task_6.sh -n 1 : ./my_task_7.sh -n 1 : ./my_task_8.sh
Por supuesto, sólo se deben agregar tareas o programas que requieran un tiempo de ejecución muy parecido.
Si se desea hacer trabajo interactivo en un nodo de cálculo, el sistema de
colas puede abrir una shell con la opción –I como se muestra en el siguiente ejemplo:
[usuario@jaula04 ~]$ cola8 -I qsub: waiting for job 384.jaula04.sct.uo to start qsub: job 384.jaula04.sct.uo ready *** Job 384.jaula04.sct.uo started on mother: at Mon Apr 13 09:52:57 CEST 2009 *** Local directory /scratch/384.jaula04.sct.uo in yeq10 created *** Flush cache memory in yeq10 *** Do not forget to move relevant information to /home destination *** Local directory is deleted after job completion ------------------------------------------------------------------- [usuario@yeq10 ~]$
Cuando se entra el comando exit en el nodo de calculo, el
trabajo finaliza. Igualmente el trabajo terminaría cuando se agote el tiempo
de ejecución especificado. La opción de ejecución en interactivo sólo está
disponible en cola8 y cola2.
En el caso de que el usuario desee utilizar interactivamente un programa gráfico (por ejemplo, MATLAB desde la ventana del programa), también es posible utilizando los procedimientos descritos en la sección de Acceso.
El comando qstat proporciona información sobre los trabajos enviados y/o sobre las colas definidas en el cluster. Otros comandos del sistema de colas se encargan de detener un trabajo (qdel), modificar parámetros de ejecución en colas (qalter), mover de una cola a otra un trabajo en espera (qmove), etc... Algunos ejemplos de uso de estos comandos son:
qstat –aqstat –qqstat –f <jobid>qstat –Qqdel <jobid>qmove <queuename> <jobid>Las páginas de manual dan información de éstos y otros comandos.
Por ejemplo, una salida típica del comando qstat -a sería:
jaula01.uniovi.es: CMQ Opteron Cluster
Req'd Req'd Ela
Job ID Username Queue Jobname SessID NDS TSK Memory Time S Time
--------------- -------- -------- ---------- ------ --- --- ------ ----- - -----
857.jaula01.sct usuario cola4 gauss03 7371 1 1 -- 96:00 R 00:05
A la izquierda se destaca el número que identifica al trabajo y a la
derecha el estatus (R, running). El comando
qstat devuelve un formato de tiempo de ejecución (CPU,
walltime, …) distinto según las opciones introducidas. Para evitar
confusiones puede usarse el comando qstat –f <jobid>, el
cual ofrece información exhaustiva sobre el trabajo (nodo de ejecución,
recursos consumidos, variables de entorno, etc) como se muestra en el
siguiente ejemplo:
[usuario@jaula04 ~]$ qstat -f 384 Job Id: 384.jaula04.sct.uo Job_Name = STDIN Job_Owner = usuario@jaula04.sct.uo resources_used.cput = 00:00:00 resources_used.mem = 7436kb resources_used.vmem = 78800kb resources_used.walltime = 00:01:48 job_state = R queue = cola8 server = jaula04.sct.uo Checkpoint = u ctime = Mon Apr 13 09:52:56 2009 Error_Path = /dev/pts/0 exec_host = yeq10/7+yeq10/6+yeq10/5+yeq10/4+yeq10/3+yeq10/2+yeq10/1+yeq10/0 Hold_Types = n interactive = True Join_Path = n Keep_Files = n Mail_Points = n mtime = Mon Apr 13 09:53:43 2009 Output_Path = /dev/pts/0 Priority = 0 qtime = Mon Apr 13 09:52:56 2009 Rerunable = False Resource_List.ncpus = 1 Resource_List.nodect = 1 Resource_List.nodes = 1:cmq:sw1:ppn=8 Resource_List.vmem = 16gb Resource_List.walltime = 96:00:00 session_id = 27609 Variable_List = PBS_O_HOME=/home/usuario,PBS_O_LANG=en_US.UTF-8, PBS_O_LOGNAME=usuario, PBS_O_PATH=/usr/local/bin:/usr/local/X11/bin:/opt/intel/fce/10.1.008/bin:/opt/intel/idbe/10.1.008/bin:/opt/intel/cce/10.1.008/bin:/opt/hpmpi/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/etc:/usr/etc:/usr/local/etc:.:/home/usuario/bin, PBS_O_MAIL=/var/spool/mail/usuario,PBS_O_SHELL=/bin/bash,PBS_SERVER=jaula04.sct.uo,PBS_O_HOST=jaula04.sct.uo, PBS_O_WORKDIR=/home/usuario,PBS_O_QUEUE=cola8 etime = Mon Apr 13 09:52:56 2009 submit_args = -m n -q cola8 -l nodes=1:cmq:sw1:ppn=8 -I start_time = Mon Apr 13 09:52:57 2009 start_count = 1