Vargas : exécution d'un travail séquentiel en batch

Vous êtes ici : Support technique → Calcul scalaire → Exécution/contrôle d'un code en batch → Code séquentiel.

Les travaux sont gerés sur l'ensemble des noeuds par le logiciel LoadLeveler. Ils sont répartis après soumission dans des "classes". Vous pouvez consulter ici les limites des classes sur Vargas.

Exemple simple de soumission

Pour soumettre un travail en batch depuis Vargas, il faut :

  1. Créer un script de soumission. Voici un exemple stocké dans le fichier pg.ll : 
    vargas : more pg.ll
# Temps CPU max. d'un processus hhh:mm:ss (1h30mn ici)
# @ wall_clock_limit = 1:30:00
# Memoire max. utilisee (ici 2 Go)
# @ data_limit = 2gb
# Nom du travail LoadLeveler
# @ job_name   = Sortie   
# Fichier de sortie standard du travail       
# @ output     = $(job_name).$(jobid)
# Fichier de sortie d'erreur du travail
# @ error      =  $(job_name).$(jobid)
# adresse si elle n'est pas a jour a l'IDRIS, facultatif
# @ notification = error
# @ queue                   

# Pour avoir l'echo des commandes
set -x

# On se place dans le repertoire temporaire TMPDIR
cd $TMPDIR

# La variable LOADL_STEP_INITDIR est automatiquement positionnee par 
# LoadLeveler au repertoire dans lequel on tape la commande llsubmit
cp $LOADL_STEP_INITDIR/a.out .

# Execution du programme
./a.out

ls -lrt
  2. Soumettre ce script (uniquement depuis Vargas) via la commande llsubmit : 
    vargas : llsubmit  pg.ll

Remarques

Mots-clefs LoadLeveler utiles

notification

Le mot-clef LoadLeveler notification peut être utilisé pour recevoir un message.
notification = complete génère un mail en fin de travail;
notification = all au démarrage et à la fin d'un travail.
Ces mails sont le seul moyen de récupérer éventuellement un message d'erreur du type WALL CLOCK limit exceeded. Nous recommandons de n'utiliser que notification = error pour ne genérer un message qu'en cas de problème.

data_limit et stack_limit

Pour spécifier la taille mémoire de la zone DATA ou de la zone STACK, utilisez les mot-clefs data_limit et stack_limit. Ainsi pour demander 3Go de DATA et 300Mo de STACK, vous devez coder comme dans l'exemple ci-dessous :

# @ data_limit=3GB
# @ stack_limit=300MB,300MB
La taille mémoire peut étre specifiée en mb, Mb ou MB pour Méga-octets et en gb, Gb ou GB pour Giga-octets (sans unité, la valeur sera prise par défaut en octets).
Pour une étude plus approfondie, consultez la page sur la gestion de la mémoire sur Vargas.

wall_clock_limit et cpu_limit

La limite de temps Elapsed associée au mot-clef wall_clock_limit est relative à l'ensemble du job. Il existe un autre paramètre LoadLeveler, cpu_limit, qui permet de limiter le temps CPU des programmes exécutés dans le job, qu'il sa'gisse d'une commande ls ou de l'exécutable principal.

L'utilisation combinée des deux mot-clefs wall_clock_limit et cpu_limit permet d'assurer l'exécution des dernières instructions d'un travail. Considérons le cas typique suivant : 

# @ data_limit = 1GB
# @ stack_limit = 200MB,200MB

# @ wall_clock_limit=1:00:00
# @ cpu_limit=45:00

# @ job_name = myjob
# @ output = $(job_name).$(jobid)
# @ error = $(job_name).$(jobid)

# @ notification = error
# @ queue

set -x

# Copy to the TMPDIR the files you need for your computation:
cp -p ... $TMPDIR
cd $TMPDIR

# Run:
./my_prog

ls -alrt

# Save to the WORKDIR  the result files you are interested in:
mkdir $WORKDIR/results.$(jobid)
cp ... $WORKDIR/results.$(jobid)

# since the WORKDIR has no backup save to Gaya the important result files
mfput -v ...

L'exécution de votre programme consomme l'essentiel du temps Elapsed du travail; cependant, vous n'êtes pas sûr à l'avance de la durée de cette phase de calcul. Comme le répertoire TMPDIR dans lequel les fichiers de résultats sont écrits est automatiquement effacé à la fin du travail, vous devez sauver ces fichiers ailleurs avant cet effacement.
Pour être sûr qu'il restera assez de temps à la fin du travail pour exécuter vos copies de fichiers et ce, même si le calcul doit être interrompu, choisissez une valeur de cpu_limit pour le programme inférieure à la valeur de wall_clock_limit du travail. Un exécutable pouvant voir ses écritures sur disque très ralenties par la charge globale de la machine (le temps Elapsed de l'executable my_prog dans le travail va fluctuer, mais pas son temps CPU), il est prudent de prendre une marge confortable entre le wall_clock_limit et le cpu_limit. Il n'est pas possible de vous donner une règle de bon sens, le ratio temps CPU/temps Elapsed variant pour chaque exécutable : il vous faudra procéder par essais successifs.
© CNRS - IDRIS, 13/01/2012