Utiliser le système de batch GE depuis le centre de calcul



Pour utiliser le système de batch GE (Grid Engine) depuis le centre de calcul, vous devez disposer d'un compte local AFS.

De façon générale, un job est une tâche (ou un ensemble de tâches) que l'utilisateur souhaite exécuter sur un noeud de calcul de la ferme du centre de calcul. Cette tâche peut être un fichier exécutable, un ensemble de commandes, un script, …
Un job peut être développé et testé sur les noeuds interactifs du centre de calcul avant d'être soumis massivement sur la ferme de calcul.

Grid Engine – L'ordonnanceur de job, qu'est-ce qu'il fait ?

Grid Engine est un ordonnanceur de jobs. L'ordonnanceur représente l'unique point d'entrée commun à tous les utilisateurs pour soumettre des jobs sur toute la ferme de calcul. Son rôle est de recevoir les jobs soumis par les utilisateurs, de les ordonnancer et de les soumettre pour exécution sur une machine de calcul (worker) appropriée et disponible.

Le but principal est d'utiliser les ressources de calcul (mémoire, espace disque, CPU) de la manière la plus efficace possible. La mutualisation de toutes les ressources de calcul pour tous les utilisateurs permet une utilisation optimale des machines de calcul et de l'ensemble de la ferme.

Pour quels types de jobs ?

Grid Engine accepte plusieurs types de jobs :

  • Jobs séquentiels mono-cœur – Job traditionnels, des segments de scripts exécutés séquentiellement, généralement une seule fois, dans une machine.
  • Jobs multi-coeurs – Jobs qui utilisent simultanément plusieurs cœurs avec une mémoire partagée dans une machine.
  • Jobs parallèles – Jobs qui se composent de tâches coopératives qui doivent toutes être exécutées en même temps, souvent avec des exigences sur la façon dont les tâches sont réparties entre les ressources. Ensemble de jobs qui travaillent et modifient le même jeux de paramètres, d'où une exécution simultanée de cet ensemble de jobs.
  • Tableau de jobs ( array jobs ) – Jobs paramètriques, le même code est exécuté avec des arguments différents. Ces tâches peuvent être exécutées en parallèle, mais sont complètement indépendantes les unes des autres. Les jobs séquentiels, multi-coeurs et parallèles peuvent être lancés en jobs tableaux.
  • Jobs interactifs – Jobs qui s'exécutent dans une session interactive ; à utiliser pour le développement et test de scripts. Attention, ces jobs ne sont pas adaptés à la soumission de calculs longs ou intensifs.

Deux plateformes de calcul coexistent : Scientific Linux SL6 (64-bit, mais compatible 32-bit), et CentOS 7 (64-bit uniquement).
Pour en savoir plus sur la ferme de calcul, voir la page http://cctools.in2p3.fr/mrtguser/info_sge_parc.php .

Comment les jobs passent-ils en exécution ?

Un job est toujours soumis à une queue d'exécution. Chaque queue d'exécution dispose de valeurs par défaut pour l'espace disque, le temps cpu et la mémoire. Il existe plusieurs queues pour les jobs ayant besoin de beaucoup de ressources (cpu, mémoire, plusieurs processeurs), et elles sont à accès restreint. Pour que le job puisse s’exécuter sur une queue de ce type, il faut que l'utilisateur soit dans le “userset” autorisé (voir la section sur les queues pour plus de détails).

Une fois soumis, le job est automatiquement vérifié pour voir s'il est autorisé à s'exécuter dans une queue particulière :

  • Si l'utilisateur demande une queue :
    • Si l'utilisateur est autorisé, l'ordonnanceur vérifie si les exigences matérielles du job demandées correspondent avec les ressources que fournit la queue
      • Si elles correspondent, et s'il y a des ressources disponibles, le job est exécuté
      • Si elles ne correspondent pas, le job reste en queue
    • Si l'utilisateur n'y est pas autorisé, le job reste en queue
  • Si l'utilisateur ne demande pas de queue :
    • L'ordonnanceur prend la première queue qui répond aux exigences
    • S'il n'a pas de queues appropriées, le job reste en queue

Toutes les queues permettent l'exécution simultanée de nombreux jobs. Le système essaie toujours de lancer de nouveaux job dans une queue la moins chargée et la plus appropriée.

Se connecter à une machine d'accueil

Pour soumettre des jobs sur la ferme de calcul, vous devez disposer d'un compte local AFS et vous connecter à une machine d'accueil :

Pour compiler et tester brièvement vos codes, ou pour soumettre des jobs, vous pouvez ouvrir une session interactive en se connectant à une machine interactive cca.in2p3.fr (voir aussi la section Job interactif ) :

> ssh [-X] <loginname>@cca.in2p3.fr

Pour utiliser SL6 plutôt que CentOS 7, se connecter à cca6.in2p3.fr.

Positionnement de l'environnement GE

Une fois connecté, vous êtes prêts à utiliser GE. L'environnement GE est automatiquement défini après le login sur une machine d'accueil.
Si vous n'utilisez pas l'environnement du CC-IN2P3 par défaut, vous devez le définir en tapant la commande :

  • Si vous êtes dans le SHELL csh ou tcsh :
> source /usr/local/shared/bin/ge_env.csh
  • Si vous êtes dans le SHELL sh, ksh ou bash :
> source /usr/local/shared/bin/ge_env.sh
  • Ou brièvement :
> ge_env

Cela positionne votre $PATH et $MANPATH , et définit d'autres variables d'environnement nécessaires pour le bon fonctionnement de GE. Vous pouvez inclure la ligne en question dans votre .cshrc (pour les csh, tcsh) ou .profile (pour les sh, ksh, bash) fichier pour ne pas le donner chaque fois que vous connectez.

Si vos jobs ont besoin de vos profiles de shell, vous devez ajouter au début de votre script, par exemple pour bash :

#! /usr/local/bin/bash -l

ou utiliser l'option “-S” lors de la soumission :

> qsub -S "/usr/local/bin/bash -l" 

A noter aussi que la variable BATCH_SYSTEM est positionnée sur GE, et la variable ENVIRONMENT sur ACCESS pour les machines interactives. Pour les jobs, selon les types de job, la variable ENVIRONMENT est positionnée sur SEQUENTIAL_BATCH, PARALLEL_BATCH ou INTERACTIVE_BATCH.

GE est très facile à utiliser. Les commandes les plus utiles sont les suivantes :

  • qsub - soumettre un job
  • qstat - examiner le statut d'un job en queue ou en exécution
  • qacct - examiner le statut d'un job terminé
  • qdel - supprimer un job de la queue

Pour une description détaillée avec toutes les options possibles, consultez les pages manuel de la commande en question :

> man <commandname>

Pour modifier les demandes de ressources des jobs déjà soumis en queue, pour suspendre et libérer un job, voir la section Commandes avancées . Voir également la liste des commandes GE.

Soumettre un job : qsub

On soumet un job à l'aide de la commande qsub avec la syntaxe suivante :

> qsub -P P_<myproject> [ options ] [ scriptfile | -- [ script args ]] 

L'option “-P P_<myproject>” est utilisée pour déclarer votre projet ; le projet “myproject” est normalement le même que le nom de votre groupe ; mais il peut être aussi un sous-groupe de votre groupe si des sous-groupes ont été créés. C'est une option obligatoire.
Les autres options ne sont pas obligatoires, mais il existe plusieurs options utiles à ne pas ignorer.
Si aucun nom de fichier n'est fourni, la commande qsub avance le curseur au début de la ligne suivante et attend que vous entriez des commandes manuellement. Ces commandes, entrées une à une, constitueront le job exécuté. On termine l'entrée des commandes en tapant Ctrl-D .

Pour connaître votre projet, tapez :

> qconf -suser <loginname>

NB. Votre loginname apparaît dans cette liste une fois que avez soumis votre premier job. Si ce n'est pas le cas, vous pouvez chercher le nom de votre projet parmi les projets définis.

Si vous faites partie de plusieurs groupes, utiliser si nécessaire la commande “newgroup” pour passer dans le groupe correspondant au projet. Voir : https://doc.cc.in2p3.fr/changer_de_groupe

Pour afficher tous les projets définis, tapez :

> qconf -sprjl

Pour afficher la configuration d'un projet spécifique, tapez :

> qconf -sprj <projectname>

Pour en savoir plus de différents options de la commande qsub , voir :

> man submit

Premier script : Hello world!

  • Créez un répertoire, par exemple ge_tests
  • Ouvrez un éditeur de texte (vi, emacs, …) de votre choix
  • Écrivez/copiez le script suivant :
#!/bin/bash

echo "\nHello World!\n"

echo 'Mon repertoire de travail est: ' 
pwd
echo 'sur la machine: ' 
hostname

sleep 60
echo "Done!!"
  • Nommer le fichier hello_world.sh et le rendre exécutable
  • Passer la commande :
> qsub -P P_<myproject> hello_world.sh

Une fois le job est soumis, l'ordonnanceur vous retournera le jobid du job :

Your job 5947764 ("hello_world.sh") has been submitted

C'est avec ce jobid que vous trouvez l'information concernant votre job ( qstat / qacct ), que vous pouvez modifier les demandes de ressources ( qalter ) ou supprimer votre job ( qdel ).

Consulter l'état des jobs en cours : qstat

Pour connaître le statut des jobs soumis qui sont encore en queue ou en exécution, tapez :

> qstat 

Cela vous donne l'information quel est le statut actuel de votre job :

job-ID  prior   name       user  state submit/start at     queue slots ja-task-
-------------------------------------------------------------------------------
5947764 0.00000 hello_worl login  qw   01/31/2012 16:22:23         1        

Ici, le statut qw (queued and waiting).

Les statuts les plus courants sont :
r : running, job en exécution
Rr : job running qui a été relancé
qw : queued and waiting, job en queue
Eqw : job en erreur en queue

Les autres status possibles sont listés ici :

Category State GE Letter Code
Pending
pending qw
pending, user hold hqw
pending, system hold hqw
pending, user and system hold hqw
pending, user hold, re-queue hRwq
pending, system hold, re-queue hRwq
pending, user and system hold, re-queue hRwq
Running
running r
transferring t
running, re-submit Rr
transferring, re-submit Rt
Suspended
job suspended s, ts
queue suspended S, tS
queue suspended by alarm T, tT
all suspended with re-submit Rs, Rts, RS, RtS, RT, RtT
Error
all pending states with errors Eqw, Ehqw, EhRqw
Deleted
all running and suspended states with deletiondr, dt, dRr, dRt, ds, dS, dT, dRs, dRS, dRT



Pour afficher les jobs se trouvant dans un état spécifique, tapez :

> qstat -s p/r/s

avec “p” pour pending, “r” pour running, et “s” pour suspended. Pour afficher les jobs d'un groupe :

> qstat -u @<groupname>

Pour obtenir des informations sur un job particulier, s'il est toujours en queue ou en exécution, tapez :

> qstat -j <jobid>

L'option “-nenv” permet de réduire la verbosité. Pour obtenir des informations sur les ressources demandées par un job :

> qstat -r

Pour obtenir des d'autres informations sur les jobs tels que le projet utilisé :

> qstat -ext

Pour connaitre toutes les options possibles, voir :

> man qstat

Obtenir des informations sur des jobs terminés : qacct

La commande qacct fourni les informations sur l'utilisation passée de GE. Un enregistrement de comptabilité est écrit dans le fichier accounting pour chaque job terminé. Ce fichier contient les données des jobs terminés durant les 5 derniers jours. Les données plus anciennes sont dans le fichier accounting correspondant au mois d’exécution. Par défaut, la commande permet d'accéder aux données des jobs 5 jours en arrière.

Pour obtenir l'information sur un job particulier déjà terminé (depuis moins de 5 jours), tapez :

> qacct -j <jobid>

Pour accéder aux données qui datent de plus de 5 jours, utilisez l'option “-f” :

> qacct -o <loginname> -j -f /opt/sge/ccin2p3/common/accounting.YYYY.MM

Par exemple, pour afficher les informations de vos jobs des 10 derniers jours :

> qacct -o <loginname> -j -d 10 -f /opt/sge/ccin2p3/common/accounting.YYYY.MM

Note : Le cpu-time des jobs est exprimé en HS06.secondes. Voir la section sur la consommation CPU des jobs pour plus de détails.

Dans la sortie de la commande “qacct -j” , il y a deux lignes utiles : failed et exit_status pouvant vous expliquer les raisons pourquoi vos jobs échouent. Si tous les deux sont “0”, votre job a été exécuté et bien terminé pour GE :

...
failed       0    
exit_status  0  
...

Sinon, il y a eu un problème :

- exit_status -

Les codes les plus fréquents :

  • Si une limite soft est dépassée, les signaux suivants sont envoyés :
exit_status corresponds to
152 = 24 (SIGXCPU) + 128SIGXCPU : dépassement de cpu ( _cpu ) ou mémoire ( _rss )
138 = 10 (SIGUSR1) + 128SIGUSR1 : dépassement du temps elapsed ( _rt )
153 = 25 (SIGXFSZ) + 128SIGXFSZ : dépassement de taille de fichier ( _fsize )
  • Si une limite hard est dépassée, un signal SIGKILL 137 = 9 (SIGKILL) + 128 est envoyé
  • Les exit_status inférieurs à 128 sont définis par l'utilisateur.



- failed -

failed indique le problème survenu dans le cas où un job n'a pas pu être démarré sur un hôte d'exécution :

failed explication
1 : assumedly before job Job could not be started
7 : before prolog Job could not be started
8 : in prolog Job could not be started
10 : in pestart Job could not be started
19 : before writing exit_status
21 : in recognizing job
25 : rescheduling Job ran, job will be rescheduled
26 : opening input/output le Job could not be started, stderr/stdout le could not be opened
28 : changing into working directoryJob could not be started, error changing to start directory
29 : invalid execution state
37 : qmaster enforced h rt limit
100 : assumedly after job Job ran, job killed by a signal


Pour en savoir plus de différents options de la commande qacct , voir :

> man qacct


Pour déchiffrer la sortie de la commande qacct , voir :

> man accounting

Supprimer un job / une tâche : qdel

Les jobs peuvent être supprimés avec la commande qdel . Vous pouvez supprimer seulement vos propres jobs.

Pour annuler l'ensemble de vos jobs :

> qdel -u <loginname>

Pour annuler un ou plusieurs jobs :

> qdel <jobid>[,jobid,...]

Pour annuler une tâche d'un array job ( cf. section Array job ):

> qdel <jobid>.<taskid>

Pour annuler plusieurs tâches d'un array job :

> qdel <jobid>.<taskid_first>-<taskid_last>[:intervalle]
# ou avec l'option "-t" :
> qdel <jobid> -t <taskid first>-<taskid last>[:intervalle]

Pour en savoir plus de différents options de la commande qdel , voir :

> man qdel

La sortie de votre job

Par défaut, lors de la soumission d'un job batch, deux fichiers seront créés dans votre $HOME une fois les jobs terminés :
<jobname>.o<jobid> (sortie standard stdout)
<jobname>.e<jobid> (erreur standard stderr)

Lors de la soumission d'un array job , ces fichiers seront nommés (il y aura autant de fichiers qu'il y a de tâches) :
<jobname>.o<jobid>.<taskid>
<jobname>.e<jobid>.<taskid>

La sortie de votre premier job Hello world! se trouve dans votre $HOME . Là, vous aurez deux fichiers :

hello_world.sh.e<jobid>   # vide, s'il n'y a pas eu d'erreurs
hello_world.sh.o<jobid>

La sortie peut être visualisée, par exemple, avec la commande cat :

> cat hello_world.sh.o5947764  
***************************************************************
*                  Grid Engine Batch System                 
*           IN2P3 Computing Centre, Villeurbanne FR         
***************************************************************
* User:                    sloikkan                         
* Group:                   ccin2p3                          
* Jobname:                 hello_world.sh                   
* JobID:                   5947764                          
* Queue:                   long                            
* Worker:                  ccwsge0632.in2p3.fr              
* Operating system:        Linux 2.6.18-238.12cc.el5        
* Project:                 P_ccin2p3                        
***************************************************************
* Submitted on:            Tue Jan 31 16:22:23 2012         
* Started on:              Tue Jan 31 16:29:15 2012         
***************************************************************

Hello World!

Mon repertoire de travail est: 
/scratch/5947764.1.long
sur la machine: 
ccwsge0632
Done!!

***************************************************************
* Ended on:                Tue Jan 31 16:29:15 2012         
* Exit status:             0                                
* Consumed                                                  
*   cpu (HS06):            11:34:10                         
*   cpu scaling factor:    11.350000                        
*   cpu time:              3669 / 259200                    
*   efficiency:            90 %                             
*   io:                    13.87236                         
*   vmem:                  1.129G                           
*   maxvmem:               6.240G                           
*   maxrss:                3.473G                           
***************************************************************

Les sorties standards stdout et stderr des jobs sont redirigées vers l'espace spool pendant l'exécution de votre job puis recopiées, par défaut, dans votre espace $HOME . Pour changer le positionnement et le nom des sorties stdout et stderr, ainsi que le jobname de votre job, voir section Options de base ci-dessous.

A noter qu'il est préférable d'avoir des fichiers de sortie stdout / stderr de taille raisonnable (moins de 100 MO). Les fichiers plus gros doivent être redirigés vers le $TMPDIR plutôt que le $HOME comme c'est le cas par défaut.

Options de base vis à vis de GE

La commande qsub (et ses dérivées qalter et qlogin) possède un grand nombre d'options. Pour en avoir une liste exhaustive, tapez :

> man submit


Les options peuvent être transférées à GE de différentes façons :

1) Via la ligne de commande : à la suite de la commande qsub lors de la soumission du job, ou à la suite de la commande qalter en cas de modifications (voir la section concernant qalter ) :

> qsub -l sps=1 scriptfile
> qalter -l hpss=1,sps=1 <jobid>

2) A l'intérieur de votre fichier script :

#$ -l sps=1

Dans ce cas, les options peuvent être mises au début du fichier script, avant toutes autres lignes correspondant à votre job. Chaque ligne contenant des options doit démarrer par le préfixe “#$” . Le préfixe peut être changé avec l'option “-C” .

3) Dans un fichier spécifique .sge_request :

-l sps=1

Ce dernier est une bonne place pour des options par défaut comme le projet, pour plus de détails, voir :

> man sge_request


Les options GE de base sont listées ci-dessous :

Options Explication
-C prefix permet de modifier le prefix utilisé dans un script pour définir les options à GE ; par défaut “#$” est utilisé
-N jobname permet de spécifier le nom du job ; par défault GE utilise le nom du script
-S /path/shell permet de spécifier le shell utilisé lors de la soumission du job
-cwd pour travailler dans le répertoire de soumission, à utiliser seulement avec les jobs parallèles ; par défaut, les outputs seront dans $HOME de l'utilisateur
-e [/ path /] filepermet de définir l'emplacement du fichier stderr
-o [/ path /] filepermet de définir l'emplacement du fichier stdout
-j [y,n] permet de fusionner les sorties stdout et stderr dans un seul fichier ; par défaut “n” (= ne pas fusionner)
-r [y,n] permet de spécifier si, dans le cas où le job échoue après une panne du système, celui-ci sera relancé ; par défaut “y” sauf pour les jobs interactifs
-a date_time permet de soumettre un job demandant son exécution à une date précise [[CC]]YY]MMDDhhmm[.SS]
-M emailaddress envoie un email à cette adresse si certains événements, spécifiées par l'option “-m” , se produisent
-m {b,e,a,s,n} “b” quand le job passe en exécution, “e” quand le job est terminé, “a” lorsque le job est abandonné, “s” lorsque le job est interrompu, “n” aucun mail ne sera envoyé (valeur par défaut). Attention, cette option peut créer des surcharges en cas d'envoi massif de mail.
-q queuename permet de définir la queue d'exécution ; seulement pour les jobs parallèles et multi-coeurs
-pe PE n permet de spécifier l'environnement parallèl (PE) et le nombre de processeurs (slots) à utiliser, voir section Job parallèle
-l resource=value ,…pour demander des ressources pour un job, voir Ressources informatiques
-V pour transférer toutes vos variables d'environnement
-p priorité permet de diminuer la priorité du job (0 par défaut, valeurs négatives possibles)



Un fichier script pourrait ainsi contenir des options suivantes :

#!/bin/sh
#####################################
# exemple job script pour options GE
#####################################

#$ -S "/usr/local/bin/bash -l" 
#$ -N jobname
#$ -o jobname.out
#$ -e jobname.err 
#$ -r y
#$ -M myname@mylabo.fr
#$ -m be   ## envoie un email quand le job commence et termine

####################################
### votre script vient ici ...


### end

L'option -clear de qsub permet d'ignorer toutes les options précédemment définies (par exemple dans le script) et de ne tenir compte que des options définies après elle dans la ligne de commande.

Dans la plupart des cas, vos jobs ont besoin d'utiliser des ressources informatiques partagées sur le cluster avec d'autres utilisateurs et/ou groupes.

Pour connaître les ressources disponibles (= complex dans le langage GE), et leur configuration, tapez :

> qconf -sc

Ou voir la page http://cctools.in2p3.fr/mrtguser/info_sge_complex.php .

Les ressources sont de types demandables et consommables (voir la sortie de la commande “qconf -sc” ) :
- La colonne requestable ( YES / NO ) indique si l'utilisateur peut demander la ressource pour son job.
- La colonne consumable indique si l'attribut est une ressource consommable ( YES / NO ). Pour chaque ressources consommables, il existe une valeur de la quantité maximale disponible de cette ressource. GE comptabilise la consommation de cette ressource pour tous les jobs en cours et assure que les jobs ne sont acheminés que s’il y a suffisamment de ressources consommables disponibles.
- La colonne default indique la valeur par défaut prise en compte si vous ne spécifiez pas une demande pour cet attribut ; ce paramètre n’est intéressant que pour les attributs de complexes consommables.

Pour certaines ressources il est possible de mettre des limites hard ( h_ ) et soft ( s_ ). Par défaut, toutes les demandes des ressources sont considérées comme hard si elles ne sont pas explicitement spécifiées comme soft. Si toutes les demandes hard ou soft d'un job ne peuvent pas être allouées, le job restera en queue. Lorsqu'une limite hard est atteinte, le job est arrêté par GE. Lorsqu'une limite soft est atteinte, le job est informé par GE (signal SIGUSR1) et peut se terminer correctement (sans dépasser la limite hard).

Ressources par groupe

Il n'y a pas de ressources spécifiques par groupe à déclarer. Les limites de chaque groupe sont gérées par la configuration de GE basé sur le projet (l'option “-P” ) que vous déclarez. Pour voir les quotas de ressources (RQS, Resource Quota Set) fixés pour votre groupe, tapez :

> qconf -srqs | grep -i <groupname>   # <groupname> sans préfixe "P_" 

ou visitez la page http://cctools.in2p3.fr/mrtguser/info_sge_complex.php , et choisissez votre groupe par son nom.

Déclaration des ressources : syntaxe

Vous devez déclarer toutes les ressources que vous souhaitez utiliser dans vos jobs. Les ressources sont à spécifier lors de la soumission d'un nouveau job (voir qsub). Elles peuvent également être modifiées pour un job déjà soumis et se trouvant encore en queue (voir qalter ). Les ressources sont aussi à déclarer lorsque vous ouvrez une session interactive sous GE (voir qlogin ).

Lors de la soumission d'un nouveau job, les ressources sont à déclarer avec la syntaxe suivante :

> qsub -l resource=value scriptfile

NB. L'option “-l” (petit “L”) n'est donnée qu'une seule fois même si vous spécifiez plusieurs ressources à la fois :

> qsub -l resource1=value1,resource2=value2,resource3=value3 scriptfile

Déclarations des ressources de système d'exploitation

Les systèmes d'exploitations Scientific Linux 6 et CentOS 7 sont disponibles sur la ferme de calcul. SL6 est le système choisi par défaut, mais il est possible de demander CentOS 7 en déclarant la ressource associée :

> qsub -l os=cl7 test.sh

Il est également possible de demander les deux systèmes d'exploitation :

> qsub -l os="sl6|cl7" test.sh

Dans ce cas, l'un ou l'autre des OS sera utilisé en fonction de ce qui est disponible.

Déclarations des ressources de stockage et de licences

Pour les ressources de stockage – dcache, hpss, irods, mysql, oracle, sps, xrootd – et de licences – idl, matlab – la valeur à donner est “1”. Par exemple :

> qsub -l hpss=1,sps=1 test.sh
> qsub -l matlab=1 test.sh

Si vous ne les utilisez pas, il n'est pas nécessaire de spécifier “hpss=0” car c'est “0” (zéro) par défaut.

Déclarations des ressources de calcul : CPU, MEMOIRE, DISQUE

Si vous ne déclarez pas les ressources de calcul – CPU, MEMORY, DISK – l'ordonnanceur vous alloue les limites maximum de la queue demandée (voir la section dédiée aux queues).

Les valeurs limites évoluent dans le temps en fonction des configurations des machines de calcul. Tout dépassement d'une valeur limite entraînera l'arrêt de l'exécution de votre job par l'ordonnanceur GE.

Pour optimiser votre script, pour connaître les valeurs du CPU consommé, mémoire, et disque requis par votre job, vous pouvez faire des tests de courte durée sur une machine d'accueil interactive ( cca ). Les informations concernant les ressources utilisées sont à votre disponibilité dans la bannière de la fin du fichier de log que vous obtenez lorsque le job est terminé.

- CPU -

Pour spécifier le temps CPU cputime (le temps CPU nécessaire pour votre job), par exemple pour demander 1 heure et 40 minutes, notez :

-l h_cpu=6000          # durée en seconds  
# ou
-l h_cpu=01:40:00      # durée en format hh:mm:ss

Lorsque la limite hard h_cpu est dépassée, le job est interrompu par un signal SIGKILL et GE tue immédiatement votre job (exit_status 137).
Si vous souhaitez que votre job soit averti de sorte qu'il peut se terminer normalement avant qu'il ne soit tué, vous devrez spécifier la limite soft s_cpu à une valeur inférieure à h_cpu . Si s_cpu est dépassée, un signal SIGXCPU, qui peut être capturé par le job, est envoyé (exit_status 152).

Pour connaître les limites hard/soft, tapez :

> qconf -sq "*" | egrep "qname|s_cpu|h_cpu" 


- MEMOIRE -

Pour spécifier la mémoire maximale nécessaire pour votre job, par exemple pour demander 2 GB, notez :

-l h_rss=2G

L'unité par défaut est un octet, les autres unités possibles sont K(ilo), M(ega), G(iga).
NB: La mémoire demandée doit être au minimum de 64M.

Si h_rss est dépassé, le job est interrompu par un signal SIGKILL et GE tue immédiatement votre job (exit_status 137).
Si vous souhaitez que votre job soit averti de sorte qu'il peut se terminer normalement avant qu'il ne soit tué, vous devrez spécifier la limite soft s_rss à une valeur inférieure à h_rss . Si s_rss est dépassée, un signal SIGXCPU, qui peut être capturé par le job, est envoyé (exit_status 152).

- DISQUE -

Lors de l'exécution d'un job sur une machine de la ferme, un espace disque local de la machine vous est alloué. Vous pouvez lire et écrire les données sur cet espace. Il est accessible à votre job à travers la variable d'environnement $TMPDIR . Cet espace est nettoyé à la fin de votre job par GE. Vous devez donc copier les données que vous souhaitez conserver dans un espace de stockage approprié.

Pour spécifier la taille maximale du fichier que le job en question peut créer, par exemple si vous avez besoin d'un maximum de 4096 Mo (ou 4 Go), vous devez spécifier :

-l h_fsize=4096M

L'unité par défaut est un octet, les autres unités possibles sont K(ilo), M(ega), G(iga).
NB: L'espace disque demandé doit être au minimum de 64M. Aucun fichier en lecture ou écriture ne doit dépasser cette limite, même en accès distant. Sinon, le job sera tué.

Aucun fichier lu ou écrit, même sur un espace de stockage distant, ne doit dépasser cette limite (le job est tué au-delà).

GE utilise la notion d'une queue pour distinguer différents types de jobs. Un job est toujours soumis à une queue. Une queue d'exécution correspond à des valeurs par défaut concernant l'espace disque, le temps cpu, la mémoire, …

Lors de la soumission d'un job, vous ne devez pas, normalement, spécifier la queue d'exécution. L'ordonnanceur vous cherche une queue optimale par rapport le cpu, la mémoire et l'espace disque demandés par votre job.

La queue doit être déclarée si vous souhaitez utiliser une queue spécifique destinée aux jobs parallèles, multi-coeurs ou démons. La queue sera spécifiée avec l'option “-q” :

> qsub -q <queuename> ... 

Il existe des queues à accès restreint (GPU, parallèles, multi-coeurs, demon, longlasting, huge) pour lesquelles vous devez faire une demande validée par votre czar. Lorsque vous utilisez ces queues, l'ordonnanceur vérifie automatiquement si vous y avez les droits ou pas, vous n’êtes pas obligés de déclarer la queue.

Pour afficher la liste des queues disponibles, tapez :

> qconf -sql

Pour afficher les propriétés d'une queue particulière, tapez :

> qconf -sq <queuename>

Ou voir la page web http://cctools.in2p3.fr/mrtguser/info_sge_queue.php et cliquer le nom de queue pour voir les caracteristiques détaillées de cette queue.

Si, dans les listings, l'attribut user_lists a une autre valeur que NONE , cela veut dire que l'accès à cette queue est restreint.

Les queues dont le nom
- commence par mc_* sont destinées aux jobs multi-coeurs
- commence par pa_* sont destinées aux jobs parallèles
- contient gpu sont destinées aux jobs GPU
- contient le mot interactive sont à utiliser dans une session interactive.

Pour les queues multi-coeurs et parallèles, le CPU et la mémoire sont exprimées par coeur, et l'espace disque est global pour le job.

Attention, la queue demon nécessite également de déclarer la ressource correspondante :

-q demon -l demon=1

Exemple d'un batch job (serial job)

#! /usr/local/bin/bash -l 

# pour specifier 10 minutes de 'wallclock time'
#$ -l h_rt=00:10:00

# pour demander 1 gigabyte de mémoire
#$ -l s_rss=1G

# pour nommer le job
#$ -N serial_exemple

# pour déclarer votre projet sous lequel le job sera exécuté
#$ -P P_<groupname>

# pour fusionner les sorties stdout et stderr dans un seul fichier
#$ -j y

# les sorties stdout et stderr se trouveront par défaut dans votre $HOME
# pour les placer ailleurs par ex. sous votre $HOME :
#$ -o $HOME/<votrePATH>/

# exécuter votre commande, et sauvegarder le résultat 
echo $(/bin/date) > resultat.txt

# votre job s’exécute dans le répertoire de travail temporaire ($TMPDIR) sur 
# les workers qui sera effacé à la fin du job ; à la fin de vos calculs, vous 
# devez copier les résultats que vous voulez garder dans un espace de stockage 
# approprié, par ex.
cp resultat.txt $HOME/myresult

Exemple d'un job avec passage de paramètres

Pour passer les paramètres, on les donne au niveau du shell script, par exemple :

> qsub $HOME/test.sh arg1 arg2 arg3

où arg1 est récupéré au moyen de la variable $1 , arg2 avec $2 et arg3 avec $3 .
Les options GE doivent être données avant le nom du script, et les autres paramètres après le nom du script.

Job interactif

Pour écrire et développer votre script vous pouvez utiliser une session interactive sous GE. Pour cela, vous devez vous connecter à une machine d'accueil cca.in2p3.fr .
Pour lancer un un job interactif, tapez :

> qlogin [ options ]

Comme options, vous devez spécifier vos demandes de ressources avec l'option “-l”, par exemple pour avoir l'acces au stockage SPS, un worker avec une queue offrant au minimum de 1 heure de limites de temps, avec la mémoire et l'espace disque de 1G :

> qlogin -l SPS=1,s_fsize=1G,s_cpu=1:00:00,s_rss=1G

Vous serez connecté directement à un worker, et votre job interactif sera géré comme un job batch. La taille de vos fichiers ne pourra pas dépasser la valeur spécifiée par l'option s_fsize .

Vous aurez également votre jobid comme pour les autres types de jobs :

Your job 6043392 ("QLOGIN") has been submitted

Il faut parfois attendre si les ressources ne sont pas disponibles, mais vous aurez ensuite votre session :

> qlogin -l SPS=1,s_fsize=1G,s_cpu=1:00:00,s_rss=1G
local configuration cca01.in2p3.fr not defined - using global configuration
JSV "/opt/sge/util/resources/jsv/corebinding.jsv" has been started
JSV "/opt/sge/util/resources/jsv/corebinding.jsv" has been stopped
Your job 6043392 ("QLOGIN") has been submitted
waiting for interactive job to be scheduled ...timeout (3 s) expired while waiting on socket fd 4
.timeout (11 s) expired while waiting on socket fd 4
.timeout (19 s) expired while waiting on socket fd 4
.timeout (36 s) expired while waiting on socket fd 4
.timeout (57 s) expired while waiting on socket fd 4
.
Your interactive job 6043392 has been successfully scheduled.
Establishing /usr/bin/qlogin_wrapper session to host ccwige0001.in2p3.fr ...
The authenticity of host '[ccwige0001.in2p3.fr]:54508 ([134.158.48.21]:54508)' can't be established.
RSA key fingerprint is bb:d7:79:14:08:d5:b1:12:28:a8:84:2c:4e:96:94:33.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[ccwige0001.in2p3.fr]:54508,[134.158.48.21]:54508' (RSA) to the list of known hosts.
sloikkan@ccwige0001.in2p3.fr's password: 

Une fois connecté, vous aurez l'accès à un dossier local correspondant à votre jobid :

> cd /scratch/6043392.1.interactive/ 

Cet espace est définit par la variable ${TMPDIR}

Pour terminer la session, tapez :

> exit

La session se terminera également si le cputime demandé est dépassé.

Vous avez à votre disposition deux types de queues interactives. La queue “interactive” est la queue par défaut, il n'est pas nécessaire de la déclarer. La queue “mc_interactive” est elle destinée aux jobs multi-coeurs, à déclarer avec l'option “-q” :

> qlogin -pe multicores <number_of_cores> -q mc_interactive

Voir aussi la section Job multi-coeur.

Job multi-coeur

La commande pour soumettre un job utilisant plusieurs coeurs sur une même machine de calcul est la suivante :

> qsub -pe multicores <number_of_cores> -q <QueueName>

Les queues disponibles pour les jobs multi-coeurs sont “mc_long”, “mc_huge” et “mc_longlasting”, à accès restreint. Les jobs multi-coeurs doivent être configurés pour utiliser le nombre de coeurs demandés, accessible à travers la variable d'environnement NSLOTS.

Job parallèle

Ces jobs sont soumis sur CentOS 7 uniquement. Vous pouvez vous connecter aux machines d'accès cca.in2p3.fr pour compiler votre code sous CentOS 7 : pour soumettre un job parallèle, vous devez d'abord compiler votre code avec une bibliothèque spécifique, OpenMPI ou MPICH et utiliser respectivement /usr/lib64/openmpi ou /usr/lib64/mpich.

Lors de la soumission :

- Définir l'environnement utilisé (openmpi ou mpich2) et le nombre de coeurs utilisés avec l'option “-pe” :

-pe <pe_environment> <number_of_cores>

Par exemple :

-pe openmpi 16


- Spécifier la queue souhaitée avec l'option “-q” dépendant de besoins (cpu, mémoire) de votre jobs :

-q <queuename>   #  pa_medium | pa_long 

Par exemple :

-q pa_long


Pour connaître les caractéristiques d'une queue, tapez :

> qconf -sq <queuename>

A noter : le cpu et la mémoire sont à calculer par coeur.
La sortie du job parallèle est écrite directement à sa destination finale lors de l'exécution du job, et pas localement sur le worker et transféré à la fin du job vers sa destination finale.
Si vous utilisez les bibliothèques OpenMPI ou MPICH, vous devez créer un fichier .mpd.conf à votre $HOME avec les droits 600 ( -rw——- ) avec le contenu suivant :

# $HOME/.mpd.conf
Secretword = XXXX    # où XXXX est un mot secret


- Si vous utilisez OpenMPI :
Soumettez ce job en spécifiant CentOS 7 avec -l os=cl7 :

-l os=cl7 -pe openmpi <number_of_cores> -q <QueueName>  

Avec dans le script :

 source /usr/local/shared/bin/openmpi_env.sh

 mpiexec -n $NSLOTS phello


Compilation :

> mpicc -o phello phello.c

Exemple de soumission de job :

> qsub -l os=cl7 -cwd -pe openmpi 16 -q pa_long phello.script


- Si vous utilisez MPICH :
Soumettez ce job par exemple en spécifiant CentOS 7 avec -l os=cl7 :

-l os=cl7 -pe mpich2 <number_of_cores>  -q <QueueName>  

Avec dans le script :

export MPICH_HOME=/usr/lib64/mpich
export PATH=${MPICH_HOME}/bin:${PATH}
export MANPATH=${MPICH_HOME}/man:${MANPATH}
MPIEXEC="/usr/lib64/mpich/bin/mpiexec"
${MPIEXEC} -iface ib0 -np $NSLOTS phello 

Compilation :

> mpicc -o phello phello.c

Exemple de soumission de job :

> qsub -l os=cl7 -cwd -pe mpich2 16 -q pa_long phello.script



Array job

Lorsque l'on veut soumettre et gérer un grand nombre de jobs similaires, le mécanisme d'array jobs peut être utile, en particulier lorsqu'on veut exécuter un même script avec différents arguments, ou différents ensembles de données. Un array job est un job qui est composé de plusieurs tâches, qui se comportent toutes comme des jobs indépendants. Le même script (= un job) est alors utilisé plusieurs fois avec différents arguments (= tâches). Ce qui change, c'est le numéro d'index qui est exporté via la variable d'environnement $SGE_TASK_ID .

On soumet un array job à l'aide de l'option “-t” avec la syntaxe suivante :

> qsub -t min[-max[:intervalle]] 

Les arguments min, max et intervalle sont disponibles par les variables d'environnement $SGE_TASK_FIRST, $SGE_TASK_LAST et $SGE_TASK_STEPSIZE, respectivement. Notez que ces variables n'indiquent pas forcement l'ordre d'exécution.

Par exemple un script array_job.sh qui lit les données de quatre différents fichiers ( input[1-4].txt ) et dit bonjours à tous les éléments se trouvant dans les fichiers 1 et 3 (intervalle 2) :

#!/bin/sh

### Fusionner les stdout et stderr dans un fichier
#$ -j y

### Poser les index 'min-max:interval'
#$ -t 1-4:2

### nommez votre output script
#$ -N hello_items

echo "Task id = $SGE_TASK_ID"

if [ -e input$SGE_TASK_ID.txt ]; then
while read file
do
echo "hello $file"
done < input$SGE_TASK_ID.txt
fi 

Les fichiers input (input[1-4].txt) :

# input1.txt
world
moon 

# input2.txt
forest
sun

# input3.txt
monkey
people

# input4.txt
banan
apple

Pour soumettre le job, tapez (les options sont données dans le fichier script) :

> qsub array_job.sh

La commande retournera :

Your job-array 1331.1-4:2 ("hello_items") has been submitted

Et vous aurez deux fichiers résultats (au lieu de quatre parce que l'intervalle = 2) :

> cat hello_items.o1331.1 
...
hello world
hello moon
...

> cat hello_items.o1331.3
...
hello monkey
hello people
...

Jobs GPU

Modifier les demandes de ressources d'un job déjà soumis : qalter

La commande qalter permet de modifier les demandes de ressources des jobs soumis avec la commande qsub et se trouvant encore en queue.

  • Pour modifier une ressource d'un job, par exemple la mémoire demandée :
> qalter -mods l_hard s_rss 2G <jobid>
  • Pour ajouter une ressource à un job, par exemple sps :
> qalter -adds l_hard sps 1 <jobid>
  • Pour supprimer une ressource d'un job, par exemple hpss :
> qalter -clears l_hard hpss <jobid>
  • Pour supprimer toutes les ressources d'un job :
> qalter -clearp l_hard <jobid>
  • Pour remplacer la liste des ressources d'un job :
> qalter -l resource=value[,resource2=value2,resource3=value3] <jobid>

Tapez “man qalter” pour voir toutes les options possibles (changement de queue, d'email, …).

Suspendre et libérer un job : qhold, qrls

Vous pouvez suspendre un ou plusieurs jobs soumis avec la commande qhold :

> qhold <jobid>

Pour libérer le job suspendu avec la commande qhold utilisez la commande qrls :

> qrls <jobid>

Il existe un certain nombre de variables d'environnement à utiliser dans vos scripts dont une liste non-exhaustive est donnée ci-dessous. Pour en savoir plus, voir

> man qsub


variable explication
$HOME Répertoire d’origine de l’utilisateur
$USER Nom de connexion de l’utilisateur
$JOB_ID ID du job, un identificateur unique affecté par GE lorsque le job a été soumis
$JOB_NAMENom du job créé à partir du nom de fichier de script qsub, peut être remplacé à l’aide de l'option -N
$HOSTNAMENom de l'hôte d'exécution
$TASK_ID Numéro d'indice de la tâche d'un array job
$NSLOTS Le nombre de points d'exécution (slots) en cours d’utilisation par un job multi-coeurs ou parallèle
$NHOSTS Le nombre d’hôtes en cours d’utilisation par un job parallèle
$QUEUE Le nom de la queue dans laquelle le job s’exécute
$TMPDIR Le chemin du répertoire temporaire du job

Le wallclock time d'un job est le temps passé entre le début du job et sa fin. Le temps CPU est le temps passé à utiliser le CPU pendant le job. Ce temps CPU peut être inférieur au wallclock dans le cas d'un job avec beaucoup d'I/O (job inefficace). Il peut être supérieur au wallclock pour un job multi-coeur (le temps CPU est multiplié par le nombre de coeurs qui calculent).

Au CC-IN2P3, le temps CPU est couramment exprimé en temps HS06. La conversion se fait en multipliant le temps “physique” par un facteur de conversion qui dépend de la puissance du coeur. Par exemple, pour un wallclock de 3h, sur un coeur ayant un facteur de normalisation de 11 HS06, on a : CPU (heure.HS06) = 3 (heures) * 11 (HS06) = 33 heures.HS06.

Dans le stdout des jobs, la ligne “cpu (HS06)” indique le temps CPU en temps(jours:heures:minutes:secondes).HS06, le “cpu scaling factor” correspond au facteur HS06 du processeur, et le “cpu time” indique le temps CPU en secondes.
Dans le résultat d'une commande “qacct”, le “wallclock” correspond comme son nom l'indique au wallclock time en secondes, et le “cpu” est le temps CPU en secondes.HS06.

  • utiliser_le_systeme_batch_ge_depuis_le_centre_de_calcul.txt
  • Dernière modification: 2019/05/10 10:21
  • par David BOUVET