Utilisation

Gestionnaire de tâches (jobs ou batchs) : OAR

 

Les principes de base et règles imposées

  • Par défaut, un job interactif ou un job batch est exécuté sur 1 cœur pour une durée maximum de 1 heure.
  • Si le nombre de cores demandés pour un job est inférieur ou égal à 40 alors le job est de type small sinon le job est de type big.
  • Le nombre maximum de cores pour tous les jobs small en exécution simultanée par utilisateur est égal à 200.
  • Pour soumettre des jobs de type big, limité à 600 coeurs, une demande d’autorisation limitée dans le temps doit être effectuée par mail à “tous_scs@cemef.mines-paristech.fr”.
  • Il est possible de demander des réservations de nodes pour une durée limitée par mail à “tous_scs_cemef@mines-paristech.fr”.
  • Il est indispensable d’indiquer une durée maximum du job cohérente afin que
    • le job ne soit pas arrêté avant la fin du calcul
    • le gestionnaire de batch puisse planifier correctement l’exécution de tous les jobs soumis.
  • Le gestionnaire de batch gère automatiquement de manière homogène la soumission du job sur les 2 types de node (1 à 16 nodes acquis en 2013 et 17 à 38 nodes acquis en 2016). Toutefois, il est possible de choisir explicitement le type de node pour l’exécution (cf chapitre “Exécuter un job en batch” ).
  • Connexion ssh direct sur les nœuds de calcul est interdite, évitant ainsi l’exécution de processus perturbateur et non pris en compte par le gestionnaire de batch.
  • Il est INTERDIT d’exécuter des calculs sur front-in1-cluster, même pour de rapides tests car partage de ce serveur pour administration du cluster, gestionnaire de batchs, connexions utilisateurs, éditions, compilations, soumission et suivi des calculs en batch !
  • Si vous essayer de lancer un job et que vous voyez ce message :
    There are not enough resources for your request
    OAR_JOB_ID=-5
    Oarsub failed: please verify your request syntax or ask for support to your admin.

    => Cela veut dire que le (ou les) noeud sur lequel vous essayer de soumettre le job est réservé. Il faut demander 1 autorisation spéciale pour pouvoir lancer un job sur ce noeud.

Exécuter un job en interactif

Pour débeugger …
Avec la demande d’un job interactif, vous êtes connectés directement sur le ou les nœuds de calcul et vous pouvez exécuter des calculs et suivre les logs ou traces à l’écran par exemple.

Demande d’un coeur :

oarsub -I

Demande de 4 coeurs :

oarsub -I -l core=4

Par défaut, le walltime est d’une heure, donc possibilité de prolonger cette durée avec le paramétrage :

oarsub -I -l core=2,walltime=4:00:00

Interactive jobs have a maximum walltime of 12 hours. Beyond, you must use batch jobs (with OAR launching script).

Demande d’un noeud de 28 coeurs pendant 12 heures :

oarsub -I -l host=1,walltime=12:00:00 -p "nbcores='28'"

Une fois connecté, le calcul peut être lancer en mode debug à l’aide de gdb.
Cela nécessite d’avoir lancé XLaunch sur son PC windows si l’on utilise putty ou conemu pour se connecter au cluster.

  mpirun -np nbCores xterm -e gdb -ex run --args executableName arg1 arg2...

Remplacer nbCores par le nombre de processeur défini avant avec oarsub.

Remplacer executableName par votre executable (chemin complet).

Remplacer arg1.. par le nombre d’arguments de votre exécutable.

nbCores fenetres vont s’ouvrir avec gdb opérant sur chacun des coeurs.
Exemple :

  mpirun -np 2 xterm -e gdb -ex run --args /home/john.doe/cimlib/bin/cimlib_driver Principale.mtc

Exécuter un job en batch

Un script adapté est nécessaire, des exemples par applicatif (cimlib, abaqus, thermocalc, …) vous sont fournis dans le répertoire linux /softs/applicatif-en-question (pour chacun des applicatif voir les indications dans le paragraphe exécution de l’applicatif)

Attention : si oubli du “-S” alors non prise en compte des paramètres #OAR du script et donc exécution sur un seul noeud

oarsub -S ./votre-script.sh

Possibilité de se connecter sur un noeud sur lequel votre job est en cours d’exécution pour observer au plus près comment il s’exécute.
Ouverture d’un shell sur le premier noeud du job “votre-job-id”
oarsub -C votre-job-id

Puis, si nécessaire, connexion sur un autre noeud utilisé par ce même job (x est le numéro du noeud) :
oarsh n-inx

Soumission d’un job en modifiant les paramètres OAR du script de lancement nommé run.oar

oarsub -l core=12 -S ./run.oar

Soumission explicite d’un job sur les nodes “2013” càd ceux avec 20 cores

oarsub -p nbcores=20 -S ./run.oar

Soumission explicite d’un job sur les nodes “2016” càd ceux avec 24 cores

oarsub -p nbcores=24 -S ./run.oar

Soumission d’un job sur les nodes qui ont été explicitement réservés pour moi

1- indiquer dans le script run.oar le nombre de core car l'option -l en mode ligne de commande n'est pas effective avec l'option -p présente 
2- soumettre le job avec la commande suivante en remplaçant biensur les noms des nodes avec ceux qui vous seront communiqués lors de la réservation effective
oarsub -p "host='n-in30' or host='n-in31' or host='n-in32' or host='n-in33'"   -S ./run.oar

Certains noeuds ont plus de RAM soit 128 Go [n-in9 à n-in16 et n-in39 et n-in40], pour les sélectionner pour vos calculs :

oarsub -p mem=128 -S ./run.oar

Chaîner exécutions de 2 jobs –  job dépendant de la fin de l’exécution d’un job précédent

job_id_1=`oarsub -S ./run1.oar | grep OAR_JOB_ID | awk -F= '{print $2}'`
oarsub -a $job_id_1 -S ./run2.oar

Réserver des coeurs

oarsub -r "2015-12-16 01:00:00" -S ./run.oar

Suppression d’un job

oardel votre-job-id

États des jobs

Liste de tous les jobs en cours d’exécution

oarstat

Liste de ses propres jobs en cours d’exécution

oarmyjobs

Propriétés du job “votre-job-id”

oarstat -fj votre-job-id

Nombre de cœurs utilisés et disponibles

oarinfo

Nombre de cœurs utilisés par chaque personne

oarinfo -u

Nombre de coeurs disponibles sur chaque noeud

oarinfo -f