Changes between Version 2 and Version 3 of ColasPBS


Ignore:
Timestamp:
Dec 13, 2010 5:33:57 PM (12 years ago)
Author:
lluis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ColasPBS

    v2 v3  
    2525   * Lo mas común es que todas las unidades de almacenamiento sean visibles des de todos los nodos de un clúster
    2626
    27 == Partes de un job en una cola PBS ==
    28 En esencia los gestores colas son muy parecidos entre sí. Sólo cambia parte de su semántica.
    29 
    30 En la gestión de colas PBS existen dos términos para referirse a la unidad cálculo: el ''node'' y el ''cpp''. Un ''node'' equivalen a las unidades físicas de cálculo (las cpus) que integran distintas cantidades de cores ''cpp'' (2, 4, 8, 16,...)
    31 
    3227== Infraestructura del GMS ==
    3328
    34 La infraestructura del ''Grupo de Meteorología de Santander'' (GMS) es la siguiente (diciembre 2010):
     29La infraestructura del ''Grupo de Meteorología de Santander'' (GMS) es la siguiente (diciembre 2010).
     30
     31'''NOTA IMPORTANTE:''' la ejecución de jobs se hace sólo desde la máquina llamada ''mar''
    3532
    3633 * '''nodos''':
     
    3936   * '''nodos nuevos:''' 12 nodos de 2 cpus de 8 cores y 16 GB de memória (nodos [031]-[036], [041]-[046])
    4037
    41  * Almacenamiento almacenamiento masivo (42 TB) visible desde todos los nodos con:
     38 * '''Almacenamiento''': visible desde todos los nodos con:
    4239  * {{{/oceano/gmeteo/users/[usario]}}}: ''HOME'' del usuario llamado [usuario]
    4340  * {{{/oceano/gmeteo/DATA}}}: almacenamiento de todos los datos (observaciones, GCMs, RCMs, ...)
     
    5047  * {{{dinamica}}}: nodos [010]-[025]
    5148  * {{{blade}}}: nodos [031]-[036] y [041]-[046]
     49
     50== Los requerimientos de un job en una cola PBS ==
     51En esencia los gestores colas son muy parecidos entre sí. Sólo cambia parte de su semántica.
     52
     53En la gestión de colas PBS existen dos términos para referirse a la unidad cálculo: el ''node'' y el ''cpp''. Un ''node'' equivalen a las unidades físicas de cálculo (las cpus) que integran distintas cantidades de cores ''cpp'' (2, 4, 8, 16,...)
     54
     55Las peticiones se hacen por un conjunto de ''flags''. El envio del job al gestor de la cola se puede hacer añadiendo todas las directrices en la línea de comandos de la aplicación, o por medio de una script (archivo de texto con instrucciones de sistema). En según que circumstancias nos va interesar hacerlo de una manera u otra, pero las dos son equivalentes. La estructura tipo de un script (llamado por ejemplo {{{job.pbs}}}) de colas tiene la siguiente estructura (se añaden todas las opciones a modo de ejemplo):
     56
     57{{{#!/bin/bash
     58### Job name
     59#PBS -N [jobname]
     60### Max run time
     61#PBS -l walltime=[HH]:[MM]:[SS]
     62### Queue name
     63#PBS -q [queueNAME]
     64### Job mail
     65#PBS -M [emailCOUNT]
     66### Standard error output
     67#PBS -e [rutaArchivo]
     68### Standard output
     69#PBS -o [rutaArchivo]
     70### Dependecy
     71#PBS -W afterany:[jobid]
     72### Number of nodes and processors per node
     73#PBS -l nodes=[N]:ppn=[M]
     74
     75cd ${PBS_O_WORKDIR
     76
     77[aplicacion]}}}}
     78
     79En esta plantilla se muestra la sintaxis de los siguientes requerimientos/especificaciones:
     80tiene que cambiar los argumentos que estén entre {{{[]}}}:
     81 * ''-N [jobname] :'' nombre del job
     82 * ''-l walltime=[HH]:[MM]:[SS] :'' duración del job (en {{{[horas]:[minutos]:[segundos]}}}).
     83 * ''-q [queue] :'' nombre de la cola a la cual se manda el job
     84 * ''-M [emailCOUNT]:'' dirección de correo donde se quiere que mande un job terminado (por lo general al correo del sistema)
     85 * ''-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})
     86 * ''-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})
     87 * ''-W 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)
     88 * ''-l nodes=[N]:ppn:[M] :'' número de nodos ({{{[N]}}}) y número de cores a coger de cada nodo ({{{[M]}}}), al cual se quiere mandar el job
     89
     90El job se mandaría a la cola con la instrucción:
     91{{{qsub job.pbs}}}
     92
     93o bien por la línea de comandos en una línea como sigue:
     94{{{qsub -N [jobname] -l walltime=[HH]:[MM]:[SS] -q [queueNAME] -M [emailCOUNT] -e [rutaArchivo] -o [rutaArchivo] -W afterany:[jobid] -l nodes=[N]:ppn=[M] [aplicacion]
     95}}}
     96
     97Todos los jobs tienen un número que los identifica que se llama [jobid]. En el clúster del GMS tiene el siguiente formato: [jobid].ce01.macc.unican.es. Cada job tiene associado los siguientes valores PBS:
     98 * '''Job ID''': identificador del trabajo (asignado por PBS).
     99 * '''Username''': propietario del trabajo (usuario que lo envió).
     100 * '''Queue''': cola en la que reside el trabajo.
     101 * '''Jobname''': nombre del trabajo dado por el usuario o establecido por PBS en caso de no especificarse.
     102 * '''NDS''': número de nodos solicitados.
     103 * '''TSK''': número de tareas solicitadas.
     104 * '''Req'd Memory''': cantidad de memoria solicitada.
     105 * '''Req'd Time''': tiempo de reloj (wallclock) solicitado.
     106
     107== Instrucciones cola PBS ==
     108Hay distintas instrucciones para gestionar los jobs de un usuario:
     109 * '''qsub [archivo].pbs''' envio del job [archivo].pbs a la cola
     110 * '''qdel [jobid]''' terminar forzosamente el job con id [jobid]
     111 * '''qstat''' permite ver el estado de los jobs gestionados. Tiene también distintos flags (se muestran los mas usuales):
     112  * ''-n1'' muestra todos los nodos a los cuales se ha mandado un job (con tantas veces el nombre del nodo, cómo cores cogidos)
     113  * ''-u [usuario]'' muestra todos los jobs de [usuario]
     114  Por lo general mestra en lista los trabajos que concidan con los criterios escogidos con la siguiente estructura:
     115{{{[jobid] [usuario] [queue] [jobname] [SessID] [NDS] [TSK] [Req' Memory] [Req' time] [S] [Time]
     116}}}
     117  Los estados [S] que puede tener un job en la cola son:
     118  * E el trabajo está saliendo después de finalizar su ejecución.
     119  * H el trabajo está capturado (''Hold'', ej. esperando que termine otro)
     120  * Q el trabajo está en cola, elegible para su ejecución.
     121  * R el trabajo está ejecutándose.
     122  * T el trabajo está en transición (moviéndose a otra localización).
     123  * W el trabajo está a la espera de alcanzar el tiempo de ejecución.
     124  * S el trabajo está suspendido.
     125
     126== ejemplos ==
     127
     128=== Wall time insuficiente ===
     129Tomamos un job sencillo de ejemplo escrito en un fichero llamado {{{prueba.pbs}}}. Este job deja una espera de 60 segundos.
     130{{{#!/bin/bash
     131### Job name
     132#PBS -N prueba
     133### Max run time
     134#PBS -l walltime=00:00:10
     135### Queue name
     136#PBS -q grid
     137### Number of nodes and processors per node
     138#PBS -l nodes=1:ppn=1
     139
     140cd ${PBS_O_WORKDIR}
     141
     142rm ${PBS_JOBNAME}.e*
     143rm ${PBS_JOBNAME}.o*
     144
     145sleep 60}}}
     146
     147Lanzando el job obtendríamos:
     148{{{[lluis@mar CursilloPBS]$ qsub prueba.pbs
     149307065.ce01.macc.unican.es
     150[lluis@mar CursilloPBS]$ qstat | grep prueba
     151307065.ce01               prueba           lluis                  0 R grid           
     152[lluis@mar CursilloPBS]$ qstat -n1 | grep prueba
     153307065.ce01.macc.uni lluis    grid     prueba      23057     1  --    --  48:00 R   --    wn001
     154[lluis@mar CursilloPBS]$ ls
     155prueba.pbs}}}
     156Pasados los 60 segundos...
     157{{{[lluis@mar CursilloPBS]$ ls
     158prueba.e307065  prueba.o307065  prueba.pbs}}}
     159Al mirar el contenido de los ficheros:
     160{{{[lluis@mar CursilloPBS]$ cat prueba.o307065
     161[lluis@mar CursilloPBS]$ cat prueba.e307065
     162=>> PBS: job killed: walltime 43 exceeded limit 10}}}
     163El tiempo dado al job es insuficiente.
     164
     165=== Mandar el job a un nodo en concreto ===
     166Si se quiere mandar el job a un nodo en concreto se substituye la línea {{{PBS -l nodes=1:ppn=1}}} por:
     167   {{{#PBS -l nodes=wn[nnn].macc.unican.es
     168}}}
     169Donde [nnn] es el nodo requerido
     170
     171=== Ocupar toda la memória de un nodo con un único job ===
     172Para ocupar toda la memória de un nodo con un único job, bastará con pedit todos los cores de un nodo de la cola. Así, si queremos toda la memória de los nodos de la cola {{{dinamica}}}, requeriríamos:
     173   {{{#PBS -l nodes=1:ppn=8
     174}}}
     175
     176=== Lanzar un job interactivo ===
     177A la hora de hacer pruebas es muy útil abrir una sessión interactiva en un nodo del clúster. Esto se hace mandando un job interactivo. La sessión que se habra durará todo el tiempo que se quiera hasta que no se le mande la instrucción de salida {{{exit}}}. La sintaxis es:
     178   {{{qsub -I -l nodes=1 -q [queue]
     179}}}
     180'''NOTA:''' 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. Tendría que utilizarse sólo para realizar pruebas que no sean muy largas. Para lanzar jobs muy largos mejor prepararse una script de shell.