Uso de Torque
Torque es un gestor de cola que permite organizar de mejor manera el uso de los recursos con los que
cuenta un determinado cluster.
Comandos
Para la correcta operación del gestor de colas, se provee de una serie de comandos a nivel de consola,
entre estos se encuentras:
• qsub : [archivo] envío del job [archivo].pbs a la cola.
• qdel : [jobid] terminar forzosamente el job con id [jobid].
• qstat : permite ver el estado de los jobs gestionados. Tiene también distintos flags (se muestran
los mas usuales):
• -q : muestra las colas disponibles y sus principales características.
• -n : muestra todos los nodos a los cuales se ha mandado un job.
• -u : [usuario] muestra todos los jobs de [usuario].
• -r : muestra la información de los procesos que estan efectivamente corriendo.
• -a : muestra los procesos que están en las colas e información adicional.
• -f [id] : muestra información detallada de como se lanzo el proceso, tiempo de ejecución,
directorio de trabajo e información varia.
• qalter permite modificar parámetros de los jobs, pero SOLO cuando se encuentran en el estado
Q (trabajo encolado).
• pbsnodes : examina los nodos que se encuentran en el clúster, sus características y cuál es su
estado:
[nodo]
state = [estado]
np = [ncpus]
properties = [cola asignada]
ntype = [tipo]
jobs = [lista de jobs que tiene ejecutándose]
status = [propiedades físicas de la unidad]
Ejemplo de uso:
[root@server ~]# pbsnodes n001
n001
state = job-exclusive
np = 4
ntype = cluster
jobs =
0/2707.admin.dominio.net,3/2812.admin.dominio.net,1/2838.admin.dominio.net,2/28
61.admin.dominio.net
status = rectime=1422543560,varattr=,jobs=2707.admin.dominio.net
2812.admin.dominio.net 2838.admin.dominio.net
2861.admin.dominio.net,state=free,netload=120195650036,gres=,loadave=4.07,ncpus
=4,physmem=3909580kb,availmem=6151012kb,totmem=9152452kb,idletime=14512623,nuse
rs=3,nsessions=5,sessions=1250 15684 20139 26464 27727,uname=Linux n001 2.6.32-
358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64,opsys=linux
mom_service_port = 15002
mom_manager_port = 15003
[root@server ~]#
El nodo n001 (con 4 cpus y 3,7 GB de memoria y está totalmente ocupada con dos trabajos (2707,
2812, 2838 y 2861).
Jobs
para enviar los trabajos al gestor de colas y este sea capaz de poder saber que acciones son las que tiene
que realizar, es que se genera un archivo en donde se especifiquen tanto los recursos que se requieren
así como las acciones propias que el usuario desea ejecutar.
Una plantilla de dicho archivo se presenta a continuación:
#!/bin/bash
#PBS -N [jobname]
#PBS -l walltime=[HH]:[MM]:[SS]
#PBS -l mem=[MM][kb/mb/gb/tb]
#PBS -q [queueNAME]
#PBS -m [flags]
#PBS -M [emailCOUNT]
#PBS -e [rutaArchivo]
#PBS -o [rutaArchivo]
#PBS -W depend=afterany:[jobid]
#PBS -t [array]
#PBS -v [variable]
#PBS -l nodes=[N]:ppn=[M]
cd ${PBS_O_WORKDIR}
use [software]
[aplicación]
En esta plantilla se muestra la sintaxis de los siguientes directivas PBS/TORQUE:
• -N [jobname] : nombre del job
• -l walltime=[HH]:[MM]:[SS] : duración del job (en [horas]:[minutos]:
[segundos]). (Opcional: asumirá por defecto el especificado en el sistema)
• -l mem=[MM][kb/mb/gb/tb] : memoria requerida y límite de la memoria (número entero) en
kb: kilobytes, mb: megas, gb: gigas, tb: teras. (Opcional: asumirá por defecto el especificado en
el sistema)
• -q [queue] : nombre de la cola a la cual se manda el job. (Opcional: asumirá por defecto el
especificado en el sistema)
• -m [flags] : indica cuando se tiene que mandar un correo. Si no se pone este requerimiento si el
job es abortado por el sistema se manda un correo al usuario (variable MAIL). Hay las
siguientes opciones (son combinables):
• n: sin correo
• a: el job es abortado por el sistema
• b: se inicia la ejecución del job
• e: el job a terminado
• -M [emailCOUNT]: dirección de correo donde se quiere que mande un job
• -e [rutaArchivo]: ruta del archivo en donde se quiere almacenar la salida estandard del error
del job (si no se indica se construye en el directorio donde está el script el archivo $
{PBS_JOBNAME}.e${PBS_JOBID})
• -o [rutaArchivo]: ruta del archivo en donde se quiere almacenar la salida estandard del job (si
no se indica se construye en el directorio donde está el script el archivo ${PBS_JOBNAME}.o$
{PBS_JOBID})
• -W depend=afterany:[jobid]: el job se mandará a la cola cuando otro job anterior (el número
[jobid]) termine su ejecución (no importa como termine)
• -t [array]: permite tratar un conjunto de jobs cómo una array. Cada job es identificado con un
único valor dado por la [array] que se construye como combinación de valores. Por ejemplo:
• 1-100: 100 jobs del 1 al 100
• 1-5,15,35: 5 jobs del 1 al 5, el 15 y el 35
• -v [variable]: para mandar un job que tome el valor [variable]
• -l nodes=[N]:ppn:[M] : número de nodos ([N]) y número de cpus a coger de cada nodo ([M])
la aplicación se repartirá en [N]x[M] cpus
Y para su envío se utilizaría el comando qsub seguido del script:
[user@server ~]$ qsub job.pbs
O haciendo uso de los los flags del comando:
qsub -N [jobname] -l walltime=[HH]:[MM]:[SS] -l mem=[MM] -q [queueNAME] -m
[flags] -M [emailCOUNT] -e [rutaArchivo] -o [rutaArchivo] -W afterany:[jobid]
-t [array] -v [variable] -l nodes=[N]:ppn=[M] [aplicación]
Ejemplos
Lanzar un job interactivo
A la hora de hacer pruebas es muy útil abrir una sesión interactiva en un nodo del clúster. Esto se hace
mandando un job interactivo. La sesión que se abra durará todo el tiempo que se quiera hasta que no se
le mande la instrucción de salida 'exit'. La sintaxis es (la cola asume 'ppn=1'):
qsub -I -l nodes=1 -q [queue]
A la hora de lanzar este tipo de jobs se tiene que ser muy consciente de que se está ocupando un nodo
del clúster.
Lanzar un job con dependencias
En este caso, no se lanzará un script listar.bash hasta que no termine la espera de 60 segundos:
[user@server ~]$ date
Mon Dec 13 17:53:57 CET 2010
[user@server ~]$ qsub prueba.pbs
307079.encina
[user@server ~]$ qsub -N listado -q grid -W depend=afterany:307079 -l
nodes=1 ./listar.bash
307080.encina
La script 'listar.bash' no se ejecutará hasta que termine 'prueba.pbs' con identificador
307079.
[user@server ~]$ qstat -n1 | grep prueba
307079.encina user grid prueba 27714 1 -- -- 48:00 R --
wn002
[user@server ~]$ qstat -n1 | grep listado
307080.encina user grid listado -- 1 -- -- 48:00 H --
--
El trabajo 307079 está ejecutándose en le nodo wn002, pero el trabajo 307080
está a la espera.
[user@server ~]$ date
Mon Dec 13 17:54:43 CET 2010
[user@server ~]$ ls
espera.bash listar.bash prueba.pbs
[user@server ~]$ date
Mon Dec 13 17:55:02 CET 2010
[user@server ~]$ ls
espera.bash prueba.pbs listar.bash prueba.e307079 prueba.o307079
El primer job ja ha finalizado. Pasados unos segundos el segundo también
termina
[user@server ~]$ date
Mon Dec 13 17:55:12 CET 2010
[user@server ~]$ ls
espera.bash listado.e307080 listado.o307080 listar.bash prueba.e307079
prueba.o307079 prueba.pbs
[user@server ~]$ cat prueba.o307079
Hola mundo
[user@server ~]$ cat prueba.e307079
Trabajo con variable
Tomamos el job sencillo de ejemplo. En este caso el tiempo de espera para la escript se lo pasaremos
como variable del job.
#!/bin/bash
### Job name
#PBS -N prueba
### Max run time
#PBS -l walltime=00:00:10
### Queue name
#PBS -q grid
### Number of nodes and processors per node
#PBS -l nodes=1:ppn=1
cd ${PBS_O_WORKDIR}
./espera.bash ${waitTIME}
