Le système de batch

Sommaire

On trouvera aussi des exemples de scripts de soumission de job ici.

Introduction

L’exécution de vos codes de calcul ou des programmes disponibles sur Osaka doit impérativement se faire par l’intermédiaire du systeme de batch : l’ordonnanceur AGE (Altair Grid Engine).

Si vous lancez directement vos codes, sans utiliser le système de batch, le code sera exécuté sur le noeud frontal et votre session sera limitée à un temps CPU total de 3 heures.

De manière générale, il est préférable de ne pas exécuter de codes directement sur le frontal.

Le système de batch orchestre l’attribution d’un code à des ressources matérielles selon deux critères principaux:

  • la disponibilité (aspect multi-utilisateur)
  • l’adéquation matérielle (nombres de processus requis, mémoire requise, etc…)

Le systême de batch se charge de trouver les ressources matérielles disponibles — et les plus adaptées — pour la charge de travail nécessaire à l’exécution du code.

Commandes usuelles

qsub
Soumission d’un job. Voir la sections « options de soumission » pour une description complète.
qstat
Consulter l’état de vos jobs en cours d’exécution ou en attente. Cette commande permet aussi de connaitre l’identifiant de vos jobs (job-ID).
La commande qstat -F -j <job-ID> affiche les détails du job sélectionné.
qacct
Consulter les propriétés d’un job terminé.
Exemple : qacct -j <job-ID> ou qacct -j <job-name>.
qdel
Annuler un job en attente ou en cours d’exécution.
Exemple : qdel -j <job-ID>
qrsh
Démarrer une session intéractive sur un (ou plusieurs) noeuds de calculs. Utile par exemple pour démarrer une session « lourde » avec un logiciel intéractif — comme matlab — ce qui allège la charge du noeud frontal.
Voir les options de soumission pour plus de détails.
qalter
Modifier les paramètres de soumission d’un job. Si le job est en cours d’exécution, la plupart des modifications nécessitent le redémarrage du job. Lors d’un redémarrage, si la modification concerne des paramètres matériels, le job est possiblement re-soumis dans la liste des jobs en attente. Dans le cas contraire, le job redémarre sur le matériel déjà alloué, sans passer par la liste d’attente.
Exemple : qalter <job-ID> <options-de-soumission>
qresub
Redémarrer un job. Souvent nécessaire après l’utilisation de la commande qalter.

Plus de détails sont fournis dans l’aide en ligne Osaka_help (h batch) ou via la documentation d’AGE (man sge_intro).

Options de soumission

Les commandes de soumission de job qsub et qrsh, ainsi que la commande de modification qalter, acceptent un certain nombre d’options permettant de spécifier le type de job, les éléments consommables nécessaires à l’exécution du job ainsi que la configuration de l’environnement d’exécution.

-N <job-name>
Spécifier le nom du job. Ce nom est une chaine de caractère arbitraire, utilisé notamment pour le suivie des jobs (commande qstat) ou le nom de fichier où sont redirigées les sorties standards (voir l’option -o).
Exemple : -N myjob
-q <type>
Spécifier le type de job. Les valeurs possibles de <type> sont : seq_short, seq_medium, seq_long et para_long.
Voir la section type de jobs pour plus de détails.
Exemple : -q seq_medium
-pe <parallel_env>
Spécifier le type de job parallèle (si le type para_long est sélectionné). Deux environnements sont disponibles : openmp et mpi.
Voir la section types de jobs pour plus de détails.
Exemple : -pe openmp 4
-t <n>-<m>:<step>
Lancer plusieurs instances d’un même jobs (job array) avec des paramètres différents. Toutes les intances de ce job auront le même numéro de job (job-ID) mais auront un numéro de task unique (task-id). Ce numéro de task aura une valeur comprise entre les valeurs fournies en argument <n> et <m> (incluses), avec un écart de <step>. Les valeurs <m> et <step> sont optionnelles et dans ce cas la valeur <n> indique le nombre total de tasks.
Pour spécifier des paramètres différents pour chaque instance du job, plusieurs méthodologies sont possibles, comme définir un fichier contenant sur chaque ligne les paramètres de chaque task, ou définir autant de fichier contenant les paramètres que de tasks, etc… On trouvera ici des exemples concrets.
Exemple : -t 100
-l <arg>=<value>
Requête de consommables. Le terme consommable désigne tout élément hardwares ou software dont l’utilisation ne peut être partagé simultanément avec un autre job. Les consommables les plus courants sont la mémoire RAM avec l’argument m_mem_free, les jetons de licence en nommant directement le logiciel, ou les accélérateurs GPU .
Voir la section requête de consommables pour plus de détails.
Exemple : -l m_mem_free=1G,matlab=1
-wd <path>
Spécifier le dossier de travail (working directory) où sera exécuté le job.
Exemple : -wd /u/cdc/bmary/myproject/thisjob
-cwd
Utiliser le répertoire courant au moment de la soummission du job comme dossier de travail où sera exéctuté le job.
Exemple : -cwd
-j <y|n>
Spécifier si les sorties standard et les sorties d’erreur doivent (y) ou non (n) être fusionnées.
Exemple : -j y
-i </path/to/a/file>
Spécifier le chemin vers un fichier qui alimentera l’entrée standard du programme. Par défaut, l’entrée standard pointe vers /dev/null.
Exemple : -i /u/cdc/bmary/myproject/inputs/thisinput
-o </path/to/a/file>
Spécifier le chemin vers un fichier qui récoltera la sortie standard. Par défaut, ce fichier est placé dans le dossier de travail (voir -wd et -cwd) et est nommé selon la syntaxe <job-name>.o<job-ID> (ou <job-name>.o<job-ID>.<task-ID> si le job est un array job). Si le fichier spécifié n’a pas de chemin absolu, c’est le chemin relatif depuis le dossier de travail qui sera utilisé.
Exemple : -o myjob.out
-M <email-address>
Spécifier l’adresse email de l’utilisateur afin de lui communiquer des informations. Plusieurs adresses peuvent être renseignée, en les chainant avec des virgules. Voir l’option -m pour réguler la nature des messages envoyés.
Attention : Seules les adresses affiliées à l’université sont acceptées.
Exemples :
-M prenom.nom@cyu.fr
-M adresse1@cyu.fr,adresse2@u-cergy.fr,adresse3@esti.fr
-m <values>
Spécifier les types d’évènements déclenchant l’envoie d’un message à l’utilisateur spécifié avec l’option -M. Les valeurs acceptés peuvent se cumuler.
b : (begin) envoie d’un message lorsque le job démarre.
e : (end) envoie d’un message lorsque le job se termine.
s : (suspend) alerter lorsque le job est suspendu (par l’utilisateur ou l’administrateur).
a : (abort) alerter lors d’une annulation ou d’un redémarrage (action de l’administrateur ou problème matériel).
n : (no) ne pas envoyer de messages.
Exemple : -m ae

Types de jobs

Il est primordial de spécifier le type de vos job, car les types ont une influence sur la sélection matérielle.

On distingue deux grands types de jobs, eux mêmes subdivisés en sous-catégories:

  • Jobs séquentiels : job n’utilisant qu’un seul processus (ce qui équivaut à un seul coeur CPU sur Osaka). En fonction du temps de calcul, on distingue plusieurs sous-catégories. Les catégories avec un temps de calcul court sont prioritaires sur les catégories avec un temps de calcul plus long. Au dela du temps de calcul alloué dans chaque catégorie, le job est stoppé.
    • Job séquentiel court (seq_short) : le temps de calcul est inférieur à 1 h en temps CPU, et inférieur à 10h en temps réel.
    • Job séquentiel médium (seq_medium) : le temps de calcul est inférieur à 24 h en temps CPU.
    • Job séquentiel long (seq_long) : le temps de calcul est inférieur à 45 jours en temps CPU.
  • Jobs parallèles (para_long) : jobs utilisant plusieurs processus de calcul en même temps. Les code de calcul parallèle sont plus rapides en temps réel que les codes séquentiels pour un même temps CPU total. On distingue plusieurs sous-catégories de jobs parallèles en fonction de la gestion de la mémoire.
    • Job parallèle openMP à mémoire partagée : tous les processus on accès à une même mémoire virtuelle, ce qui impose que tous les processus soient exécutés sur un unique noeud de calcul.
    • Job parallèle MPI à mémoire distribuée : chaque processus possède sa propre mémoire, distincte des autres processus, ce qui implique que chaque processus peut être exécuté sur un noeud de calcul différent.
    • Job parallèle hybride : les deux types de parallélisation précédents sont utilisés.

Dans le cas d’un job parallèle, le type de job parallèle est précisé à l’aide de l’option -pe, suivit de l’un des arguments suivants :

  • openmp <N>, avec <N> le nombre de processus parallèles demandés.
    Exemple pour un job openm avec 4 processus : -pe openmp 4
  • mpi<X> <Y>, avec <X> le nombre de processus par noeud de calcul, et <Y> le nombre de processus total.
    Exemple pour un job MPI avec 4 processus répartis sur 4 noeuds de calcul : -pe mpi1 4
    Exemple pour un job MPI avec 6 processus répartis sur 3 noeuds de calcul : -pe mpi2 6

Requêtes de consommables

Les requête de consommables sont spécifiés à l’aide de l’option -l, suivie d’un couple <argument>=<valeur>.

Deux syntaxes sont possibles :

  • La syntaxe concise, qui enchaine les arguments-valeurs en les séparant par des virgules : -l arg1=value1,arg2=value2 ;
  • La syntaxe éclatée, qui fait autant d’appels à l’option -l qu’il y a de couples arguments-valeurs : -l arg1=value1 -l arg2=value2.
m_mem_free=<value><unit>
Réservation de la mémoire RAM. La valeur est un entier ou un nombre decimal, suivit d’une unité parmi K, M, G
Attention : la réservation mémoire est obligatoire.
Exemple : -l m_mem_free=1.5G
ib=<qdr|edr>
Choix du pool de noeuds de calcul en fonction du réseau infiniband. Les deux pools disponibles sont le pool qdr (40 Gb/s) et le pool edr (100 Gb/s). Voir la section dédiée décrivant l’architecture d’Osaka.
Attention : cette option est obligatoire pour les jobs parallel MPI.
Exemple : -l ib=edr
gpu=<number>
Accès à un accélérateur GPGPU (General Purpose GPU). La valeur attendue est un entier précisant le nombre d’accélérateur demandé (un seul suffit !).
Attention : l’accès au accélérateurs GPU nécessite une demande explicite auprès des administrateurs (ticket ou email).
Exemple : -l gpu=1
<logiciel>=<number>
Accès à un logiciel propriétaire, comme Comsol ou Matlab, ou accès à une toolbox Matlab. La liste des logiciels concernés, ainsi que le nombre de jetons de licences disponibles pour chaque logiciel sont accessibles via la commande lmstat.
On trouvera des exemples concrets de scripts de soumission impliquant un logiciel à jeton ici.
Exemple : -l matlab=1,image_tbx=1

Exemples de soumission de job

Voici un exemple de commande de soumission de job :

qsub -N test1 -q seq_medium -l m_mem_free=1G -m n -cwd ./myprogram

Analysons les caractéristiques de ce job:

  • Le job s’appelle test1 (option -N test1).
  • Il s’agit d’un job séquentiel dont la durée en temps CPU est inférieure à 24 h (-q seq_medium).
  • 1 Go de mémoire RAM sont réservés pour son exécution (-l m_mem_free=1G).
  • Aucun messages ne seront envoyés à l’utilisateur (-m n)
  • Le répertoire courant d’où est lancé cette commande servira de dossier de travail (-cwd)

Script de soumission de job

Comme le nombre d’options à fournir pour décrire correctement un job est relativement élevé, une commande de soumission devient vite pesante. Dans la pratique, on comprend qu’il n’est pas viable de procéder ainsi. C’est pourquoi il est plus efficace de grouper les options dans un fichier — ou script. De plus, il est alors possible d’y inclure d’autres commandes, comme le chargement des modules nécessaires, la définition de variables d’environnement ou d’autres traitements spécifiques. Encapsuler toutes ces informations dans un script augmente grandement la lisibilité du processus, et permet d’archiver — et de réutiliser — l’ensemble de ces commandes.

Un script de batch doit se plier à une syntaxe simple, mais spécifique.

  • Les options à fournir à la commande qsub du système de batch doivent être écrits sous la forme d’un commentaire shell — avec un # au début de la ligne — suivi du caractère dollar ($). Le système de batch reconnaîtra comme option de soumission toute ligne commençant par ces deux caractères #$.
  • Une ligne commençant par # sans le caractère dollar sera considéré comme un commentaire classique.
  • Toutes les autres lignes seront lues comme un script bash.

Pour exemple, voici un script de job reprenant les éléments de l’exemple de la section précédente.

#$ -N test1
#$ -q seq_medium
#$ -l m_mem_free=1G
#$ -m n
#$ -cwd

# Ceci est un commentaire

./myprogram

Pour soumettre le job associé à un tel script, on utilise le nom du script comme unique argument de la commande qsub :

>> qsub test1.job

On trouvera de nombreux exemples dans la section exemples de scripts de jobs ou dans l’aide en ligne osaka_help avec la commande h script.

Variables d’environnement

Certaines valeurs spécifiés dans les options et arguments présentés ci-avant peuvent être récupérés dans des variables d’environnement déclarées par le ystème de batch. Elles peuvent être utiles dans vos scripts. Voici la liste des plus utiles (vous trouverez une liste complète dans le man de qsub).

JOB_ID
Numéro du job donné par le système de batch.
JOB_NAME
Nom du job tel que spécifié avec l’option -N.
SGE_TASK_ID
Numéro de task pour un job array, tel que déclaré avec l’option -t.
SGE_TASK_FIRST, SGE_TASK_LAST, SGE_TASK_STEPSIZE
Respectivement, numéro de task min, numéo de task max, interval de numérotation entre les tasks.
NSLOTS
Nombre de slots parallèles alloués.
Pour un job parallèle openMP, il s’agit du nombre threads, correspondant au nombre de coeurs CPU alloués.
Pour un job parallèle MPI, il s’agit du nombre de process MPI, correspondant au nombre de coeurs CPU alloués.
Pour un job hybride, il s’agit du nombre de process MPI. Le nombre de coeurs CPU correspont au nombre de process MPI multiplié par le nombre de threads openMP.
NHOSTS
Nombre de noeuds de calcul utilisés par un job parallèle.
HOSTNAME
Nom du noeud de calcul sur lequel est exécuté le job (ou l’une des intances du job).
SGE_CWD_PATH
Chemin absolu vers le dossier d’où le job a été lancé.
SGE_STDIN_PATH, SGE_STDOUT_PATH, SGE_STDERR_PATH
Chemin absolus vers, respectivement, l’entrée standard (option -i), la sortie standard (option -o), l’erreur standard (voir l’option -j).
TMPDIR
Chemin absolu vers le dossier temporaire alloué sur le(s) noeud(s) de calcul.