Soumettre un job

Pour soumettre des jobs sur la plateforme de calcul, vous devez disposer d’un compte “calcul” et vous connecter sur un serveur interactif :

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

L’option -X permet d’ouvrir une session en mode graphique. Une fois connecté, vous pouvez compiler et tester brièvement vos codes, puis soumettre des jobs sur la plateforme de calcul.

Note

Des jobs peuvent également être exécutés au sein de sessions interactives, voir pour cela la section dédiée aux jobs interactifs.

La commande qsub

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

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

Les options peuvent également être spécifiées à l’intérieur du script. Elles doivent dans ce cas être mises au début du 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). 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. Pour connaître votre projet, tapez :

% qconf -suser <loginname>

Attention

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.

Pour afficher tous les projets définis, tapez :

% qconf -sprjl

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

% qconf -sprj <projectname>

Note

Si vous faites partie de plusieurs groupes, utilisez la commande newgroup pour passer dans le groupe correspondant au projet. Voir la section dédiée pour plus de détails.

Les autres options ne sont pas obligatoires, mais il existe plusieurs options utiles à ne pas négliger :

-C <prefix>
permet de modifier le préfixe utilisé dans un script pour définir les options à UGE (#$ par défaut)
-N <jobname>
permet de spécifier le nom du job ; par défault UGE utilise le nom du script
-S <shell path>
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>
permet de définir l’emplacement du fichier stderr
-o <path>
permet 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>
permet de soumettre un job demandant son exécution à une date précise [[CC]]YY]MMDDhhmm[.SS]
-M <emailaddress>
envoie un e-mail à 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-cœurs
-pe
permet de spécifier l’environnement parallèle et le nombre de cœurs à utiliser, voir les sections Jobs multi-cœurs et Jobs parallèles
-l <resource1=value,resource2=value,...>
pour demander des ressources pour un job, voir Déclaration des ressources
-V
pour transférer toutes vos variables d’environnement
-p <priority>
permet de diminuer la priorité du job (0 par défaut, valeurs négatives possibles)

Pour plus de détails sur les différentes options de la commande qsub, voir :

% man submit
# ou
% man qsub

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.

Déclaration des ressources

Stockage et licences

Il est nécessaire de déclarer les systèmes de stockage accédés par vos jobs, ainsi que les éventuelles licences logicielles utilisées. Cette déclaration se fait en utilisant l’option -l de la commande qsub. Pour les ressources de stockage : dcache, hpss, irods, mysql, oracle, sps, xrootd. Pour les ressources de licenses : idl, matlab etc. Par exemple :

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

Si vous n’utilisez pas une ressource, il est inutile de la déclarer, la valeur par défaut étant 0 (zéro).

CPU, mémoire, disque

Si vous ne déclarez pas les ressources de calcul (CPU, mémoire, disque), 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 de la configuration des serveurs de calcul. Tout dépassement d’une valeur limite entraînera l’arrêt de l’exécution de votre job par l’ordonnanceur.

Note

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 un serveur interactif (cca). Les informations concernant les ressources utilisées sont également à votre disponibilité dans la bannière de la fin du fichier de log que vous obtenez lorsque le job est terminé.

Ressource CPU

Pour spécifier le temps CPU nécessaire pour votre job, utilisez la ressource h_cpu ou s_cpu. Par exemple pour demander 1 heure et 40 minutes, notez :

-l h_cpu=6000          # durée en seconds en "hard limit"
# ou
-l s_cpu=6000          # durée en seconde en "soft limit"
# ou
-l s_cpu=01:40:00      # durée en format hh:mm:ss en "soft limit"
# ou
-l h_cpu=01:40:00      # durée en format hh:mm:ss en "hard limit"

Lorsque la limite hard h_cpu est dépassée, le job est interrompu par un signal SIGKILL et l’ordonnanceur tue immédiatement votre job (exit_status 137). Si vous souhaitez que votre job soit averti afin qu’il puisse se terminer normalement avant qu’il ne soit tué, vous devrez spécifier la limite soft s_cpu à la place et à 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). Si votre job dépasse la limite pendant un temps supérieur à l’attribut NOTIFY de la queue sur laquelle il tourne, il sera alors tué. Pour connaître les limites hard / soft et les attributs, tapez :

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

ou allez voir la page web dédiée aux queues.

Ressource mémoire

Pour spécifier la mémoire maximale nécessaire pour votre job, utilisez la ressource h_rss ou s_rss. Par exemple pour demander 2 GB, notez :

-l h_rss=2G             # hard resource
# ou
-l s_rss=2G             # soft resource

L’unité par défaut est un octet, les autres unités possibles sont K(ilo), M(ega), G(iga).

Note

La mémoire demandée doit être au minimum de 64M.

Comme pour la ressource CPU, si h_rss est dépassé, le job est interrompu par un signal SIGKILL et l’ordonnanceur tue immédiatement votre job (exit_status 137). Si vous souhaitez que votre job soit averti afin qu’il puisse se terminer normalement avant qu’il ne soit tué, vous devrez spécifier la limite soft s_rss à la place et à 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). Si votre job dépasse la limite pendant un temps supérieur à l’attribut NOTIFY de la queue sur laquelle il tourne, il sera alors tué.

Ressource disque

Lors de l’exécution d’un job, un espace disque local du serveur de calcul 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 automatiquement supprimé à la fin de votre job. 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, utilisez la ressource h_fsize ou ``s_fsize`. Par exemple si vous avez besoin d’un maximum de 4096 Mo (ou 4 Go), vous devez spécifier :

-l h_fsize=4096M             # hard resource
# ou
-l s_fsize=4096M             # soft resource

L’unité par défaut est un octet, les autres unités possibles sont K(ilo), M(ega), G(iga).

Note

La limite h_fsize demandée doit être au minimum de 64M.

Note

Aucun fichier lu ou écrit ne doit dépasser cette limite h_fsize, même sur un espace de stockage distant. Sinon, le job sera tué.

Queues

L’ordonnanceur utilise la notion de queue pour distinguer différents types de jobs. Un job est toujours soumis sur une queue. Une queue d’exécution correspond à des valeurs par défaut concernant l’espace disque, le temps cpu, la mémoire etc. Lors de la soumission d’un job, vous ne devez en principe pas spécifier la queue d’exécution. L’ordonnanceur vous cherche une queue optimale par rapport au 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-cœurs, démons ou une queue à accès restreint. La queue sera spécifiée avec l’option -q :

% qsub -q <queuename> ...

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 consultez cette page.

Note

Les queues dont le nom :

  • commence par mc_ sont destinées aux jobs multi-cœurs.
  • 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.

Attention

Pour les queues multi-cœurs et parallèles, le CPU et la mémoire sont exprimées par cœur, et l’espace disque est global pour le job.

Il existe des queues à accès restreint (GPU, parallèles, multi-cœurs, 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é de déclarer la queue lors de la soumission. Si, dans les propriétés d’une queue, l’attribut user_lists a une autre valeur que NONE, cela veut dire que l’accès à cette queue est restreint.