Ci-dessous, les différences entre deux révisions de la page.
Prochaine révision | Révision précédente | ||
ressources:slurm4cbp [2016/02/05 09:48] equemene créée |
ressources:slurm4cbp [2023/12/01 11:00] equemene [Ressources du Centre Blaise Pascal] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== Utilisation de Slurm au Centre Blaise Pascal ====== | + | ====== Utilisation de Cluster@CBP avec Slurm au Centre Blaise Pascal ====== |
===== Ce qu'il faut retenir ! ===== | ===== Ce qu'il faut retenir ! ===== | ||
- | * pour se connecter sur la passerelle de cluster : <code>ssh <login>@lethe.cbp.ens-lyon.fr</code> | + | * pour se connecter sur la passerelle de cluster : <code>ssh <login>@cocyte.cbp.ens-lyon.fr</code> |
- | * pour connaître les noeuds disponibles : ''qhost'' | + | * pour connaître les noeuds disponibles ou les queues : ''sinfo'' |
- | * pour connaître l'état des tâches : ''qstat'' | + | * pour connaître l'état des tâches : ''squeue'' |
- | * pour connaître la listes des queues : ''qconf -sql'' | + | * pour effectuer une réservation en mode interactif : ''srun %%--%%pty bash'' |
- | * pour lancer une tâche définie par le script GridEngine ''MyJob.qsub'' : ''qsub MyJob.qsub'' | + | * pour lancer une tâche définie par le script SLURM ''MyJob.slurm'' : ''sbatch MyJob.slurm'' |
- | ===== Introduction ===== | + | Comme "pense-bête" est disponible cette intéressante //[[https://slurm.schedmd.com/pdfs/summary.pdf|Reference Card]]//. |
+ | ===== Contexte : exécution de tâches "mode intéractif" ou "mode non connecté" ===== | ||
+ | |||
+ | Généralement, l'exécution d'un programme au CBP sur une machine se fait via un terminal en ligne de commande. Les tâches, listées dans un script, s'exécutent sur la machine hôte les unes après les autres. Se déconnecter de son terminal met fin à l'exécution de son programme. Avec **tmux** ou **screen**, il est possible de maintenir ses exécutions en se "détachant" de son terminal pour y revenir ensuite. | ||
+ | |||
+ | Il est très profitable d'avoir un "soumissionneur" pour distribuer ses tâches à un ensemble de ressources disponibles, sans avoir à se connecter de manière individuelle sur chaque machine. L'exploitation de programmes parallèlisés s'exécutant de manière concurrente sur plusieurs coeurs d'une même machine ou sur plusieurs machines | ||
+ | |||
+ | Le "soumissionneur" (ou //batch scheduler//) est un outil permettant l'exécution de tâches en //"mode non connecté"// ou en //"mode non intéractif"// sur un ensemble de ressources sans que l'utilisateur ait à choisir où et quand ses tâches vont être traitées. | ||
+ | |||
+ | ===== Ressources du Centre Blaise Pascal ===== | ||
Le Centre Blaise Pascal dispose de plateaux techniques, notamment des noeuds de clusters, destinés : | Le Centre Blaise Pascal dispose de plateaux techniques, notamment des noeuds de clusters, destinés : | ||
Ligne 21: | Ligne 30: | ||
Le Centre Blaise Pascal n'a pas vocation à voir ses infrastructures utilisées : | Le Centre Blaise Pascal n'a pas vocation à voir ses infrastructures utilisées : | ||
* pour de longs calculs de production (de l'ordre de la semaine) | * pour de longs calculs de production (de l'ordre de la semaine) | ||
- | * pour des calculs sur de très grands nombres de coeurs (de l'ordre du millier) | + | * pour des calculs sur de très grands nombres de coeurs (supérieurs à 1000) |
Pour ces deux exigences, le [[http://www.ens-lyon.fr/PSMN/doku.php?id=documentation:clusters:accueil|PSMN | Pour ces deux exigences, le [[http://www.ens-lyon.fr/PSMN/doku.php?id=documentation:clusters:accueil|PSMN | ||
dispose d'une infrastructure de production]]. | dispose d'une infrastructure de production]]. | ||
- | Les équipements mis à disposition 76 noeuds dans 3 groupes différents pour un total de 624 coeurs et 1856 Go de RAM. | + | Les équipements accessibles via le soumissionneur SLURM sont 96 noeuds répartis de 4 types différents pour un total de 1888 coeurs et plus de 8 TB de RAM agrégées. |
- | + | ||
- | Les noeuds v40z et v20z ont été arrêtés puis déposés suite à l'arrivée de Equip@Meso : ils ont été remplacés par quelques x41z supplémentaires durant l'été 2013. Les noeuds R410 sont arrivés au printemps, remplaçant les v20z version 2. Les noeuds C6100 sont ds équipements de prêt connectés un chassis hôte de GPGPU C410X. | + | |
| **Cluster** | **Marque** | **Modèle** | **Noeuds** | **Coeurs /Noeud** |**RAM /Noeud**|**Réseau GE**|**Réseau IB**|**Total Coeurs**|**Total RAM**| | | **Cluster** | **Marque** | **Modèle** | **Noeuds** | **Coeurs /Noeud** |**RAM /Noeud**|**Réseau GE**|**Réseau IB**|**Total Coeurs**|**Total RAM**| | ||
- | | **r410** | Dell | R410 | 48 | 8 | 24Go | GE | IB | 384 | 1.1 To | | + | | **c82** | Dell | C8220 | 64 | 8 | 128 GB | GE | IB | 1024 | 8192 GB | |
- | | **x41z** | Sunfire | x41z | 24 | 8 | 16Go ou 32Go | GE | IB | 192 | 512 Go | | + | | **c61** | Dell | C6100 | 16 | 12 | 24 GB | GE | IB | 192 | 384 GB | |
- | | **c6100** | Dell | C6100 | 4 | 12 | 48Go | GE | IB | 48 | 192 Go | | + | | **c82gluster** | Dell | C8220 | 4 | 16 | 256 GB | GE | IB | 32 | 1024 GB | |
Ces clusters partagent exactement la même image de système, [[developpement:productions:sidus|Sidus]] (pour Single Instance Distributing Universal System), un système complet Debian intégrant tous les paquets scientifiques ainsi que de nombreux paquets de développement. | Ces clusters partagent exactement la même image de système, [[developpement:productions:sidus|Sidus]] (pour Single Instance Distributing Universal System), un système complet Debian intégrant tous les paquets scientifiques ainsi que de nombreux paquets de développement. | ||
Ligne 39: | Ligne 46: | ||
===== Accès aux clusters ===== | ===== Accès aux clusters ===== | ||
- | L'accès aux clusters se fait via la passerelle ''lethe.cbp.ens-lyon.fr'', par le protocole SSH :<code> | + | L'accès aux clusters se fait via la passerelle ''cocyte.cbp.ens-lyon.fr'', par le protocole SSH :<code> |
- | ssh -X <login>@lethe.cbp.ens-lyon.fr</code> ou via [[http://wiki.x2go.org/doku.php|x2go]] sur la même adresse. Il est donc préalablement nécessaire d'installer sur sa machine un client SSH ou x2go pour accéder à la passerelle. | + | ssh -X <login>@cocyte.cbp.ens-lyon.fr</code> ou via [[http://wiki.x2go.org/doku.php|x2go]] sur la même adresse. Il est donc préalablement nécessaire d'installer sur sa machine un client SSH ou x2go pour accéder à la passerelle. |
En outre, cette passerelle n'est accessible que de l'intérieur de l'ENS : il est nécessaire de passer par la passerelle de l'ENS ''ssh.ens-lyon.fr'' ou par le Virtual Private Network par OpenVPN pour y accéder. | En outre, cette passerelle n'est accessible que de l'intérieur de l'ENS : il est nécessaire de passer par la passerelle de l'ENS ''ssh.ens-lyon.fr'' ou par le Virtual Private Network par OpenVPN pour y accéder. | ||
Ligne 48: | Ligne 55: | ||
===== Dossiers personnels ===== | ===== Dossiers personnels ===== | ||
- | Sur la passerelle ''lethe'', chaque utilisateur dispose de 3 espaces utilisateurs : | + | Sur la passerelle ''cocyte'', chaque utilisateur dispose de 5 espaces de travail : |
- | * un local dans ''/home/<login>'' | + | * un **personnel cluster** dans ''/home/<login>'' |
- | * un général dans ''/cbp/<login>'' | + | * un **personnel CBP** dans ''/cbp/<login>'' |
- | * un rapide dans ''/scratch'' | + | * un **projets** dans ''/projects'' |
+ | * un **//temporaire// rapide** dans ''/scratch'' | ||
+ | * un **//temporaire// très rapide** dans ''/distonet'' | ||
- | Le second correspond à l'espace utilisateur de ressources informatiques du CBP lorsqu'il se connecte : | + | L'espace **personnel CBP** correspond à l'espace utilisateur de ressources informatiques du CBP lorsqu'on se connecte : |
- | * aux 21 stations de travail de la salle libre service | + | * Toute machine de [[http://www.cbp.ens-lyon.fr/python/forms/CloudCBP|Cloud@CBP]] notamment : |
- | * à la station graphique 3D de la petite salle de réunion | + | * aux 22 stations de travail de la salle de formation du CBP |
- | * aux machines à la demande SIDUS (Single Instance Distributing Universal System) | + | * aux 13 stations de travail de la salle de formation du département de biologie |
- | * aux serveurs d'intégration, de compilation, de tests | + | |
- | * sous différentes architectures matérielles : x86_64, AMD64, ARM, (PowerPC, Sparc) | + | |
- | * sous différents systèmes 32 bits ou 64 bits | + | |
- | * sous différentes distributions Debian : Lenny, Squeeze, Wheezy, Jessie et Sid | + | |
===== Paramétrage de l'accès aux grappes de calcul ===== | ===== Paramétrage de l'accès aux grappes de calcul ===== | ||
Ligne 88: | Ligne 93: | ||
+-----------------+ | +-----------------+ | ||
</code> | </code> | ||
- | * Copie de la clé publique comme clé d'autorisation de connexion sans mot de passe :<code> cd $HOME/.ssh | + | * Copie de la clé publique comme clé d'autorisation de connexion sans mot de passe :<code>cd $HOME/.ssh |
- | cp id_rsa.pub authorized_keys</code> | + | cat id_rsa.pub >> authorized_keys</code> |
- | * Test de connexion locale : <code>ssh lethe</code> | + | * Test de connexion locale : <code>ssh cocyte</code> |
+ | |||
+ | Normalement, on se connecte sans avoir à entrer un quelconque mot de passe. | ||
===== Accès aux ressources ===== | ===== Accès aux ressources ===== | ||
- | L'utilisation de [[http://gridscheduler.sourceforge.net/|GridEngine]] permet de : | + | L'utilisation de [[https://computing.llnl.gov/linux/slurm/|SLURM]] permet de : |
- | * connaître les ressources disponibles : commande ''qhost'' et ses options | + | * connaître les ressources disponibles : commande ''sinfo'' et ses options |
- | * connaître l'état des calculs en cours : commande ''qstat'' et ses options | + | * connaître l'état des calculs en cours : commande ''squeue'' et ses options |
- | * lancer un calcul autonome (sous forme de batch) : commande ''qsub'' et ses options | + | * lancer une réservation de machines en mode interactif : commande ''srun'' et ses options |
+ | * lancer un calcul autonome (sous forme de batch) : commande ''sbatch'' et ses options | ||
+ | |||
+ | Ce [[https://slurm.schedmd.com/pdfs/summary.pdf|résumé sur Slurm]] reprend les commandes importantes. | ||
==== Connaître les ressources disponibles ==== | ==== Connaître les ressources disponibles ==== | ||
- | La commande ''qhost'' permet de connaître l'état des noeuds gérés par le gestionnaire de tâches. Chaque ressource représente un coeur. Il existe donc plus entrées par noeud. | + | La commande ''sinfo'' permet de connaître l'état des noeuds gérés par le gestionnaire de tâches. |
- | === ''qhost'' pour toute l'infrastructure === | + | <code> |
- | + | PARTITION AVAIL TIMELIMIT NODES STATE NODELIST | |
- | La commande fournit en sortie :<code> | + | r422 up infinite 6 drain r422node[3-4,33,52,56,59] |
- | HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS | + | r422 up infinite 1 mix r422node34 |
- | ------------------------------------------------------------------------------- | + | r422 up infinite 12 alloc r422node[1-2,53-55,57-58,60-64] |
- | global - - - - - - - | + | r422 up infinite 45 idle r422node[5-32,35-51] |
- | c6100gpu-1.cluster.zone lx26-amd64 24 - 47.3G - 0.0 - | + | r410 up infinite 48 down* r410node[1-48] |
- | ... <snip><snip> | + | c82gluster up infinite 4 idle c82gluster[1-4] |
- | c6100gpu-4.cluster.zone lx26-amd64 24 - 47.3G - 0.0 - | + | s92* up infinite 12 idle s92node[1-12] |
- | lethe.cluster.zone lx26-amd64 4 0.31 15.7G 3.0G 17.2G 2.9M | + | |
- | r410node1.cluster.zone lx26-amd64 16 - 23.6G - 0.0 - | + | |
- | ... <snip><snip> | + | |
- | r410node9.cluster.zone lx26-amd64 16 0.01 23.6G 303.9M 0.0 0.0 | + | |
- | x41z1.cluster.zone lx26-amd64 8 - 31.5G - 0.0 - | + | |
- | ... <snip><snip> | + | |
- | x41z9.cluster.zone lx26-amd64 8 2.16 13.7G 286.5M 0.0 0.0 | + | |
</code> | </code> | ||
- | === ''qhost <noeud>'' pour un noeud unique === | + | La colonne ''STATE'' renseigne sur l'état des machines. Par exemple : |
+ | * les noeuds du cluster **r410** sont tous éteints | ||
+ | * les noeuds **r422node3** ou **r422node59** sont indisponibles à l'usage | ||
+ | * les noeuds du cluster **s92** de **s92node1** à **s92node12** sont disponibles | ||
+ | * les noeuds **r422node1** ou **r422node64** sont utilisés pour des calculs | ||
- | Par exemple, la commande ''qhost x41z7.cluster.zone'' pour examiner les ressources offertes par le noeud **x41z7** sort :<code> | ||
- | HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS | ||
- | ------------------------------------------------------------------------------- | ||
- | global - - - - - - - | ||
- | x41z7.cluster.zone lx26-amd64 8 0.05 31.5G 342.7M 0.0 0.0 | ||
- | </code> | ||
- | Donc, le noeud x41z7 offre 8 CPU et une mémoire vive de 31.5 Go. | + | ==== Connaître l'état des calculs en cours squeue ==== |
- | === qconf pour lister toutes les grappes === | ||
- | Pour lister toutes les grappes de calcul, on applique la commande ''qconf -shgrpl'' :<code> | ||
- | @c6100 | ||
- | @r410 | ||
- | @x41z | ||
- | </code> | ||
- | === ''qconf -shhrp @<grappe>'' pour lister les noeuds d'une grappe particulière === | + | === Pour connaître l'état général === |
- | Pour lister les noeuds de la grappe **x41z**, on applique la commande ''qconf -shgrp @x41z'' :<code> | + | <code>squeue</code> |
- | group_name @x41z | + | |
- | hostlist x41z1.cluster.zone x41z10.cluster.zone x41z11.cluster.zone \ | + | |
- | x41z12.cluster.zone x41z13.cluster.zone x41z14.cluster.zone \ | + | |
- | x41z15.cluster.zone x41z16.cluster.zone x41z2.cluster.zone \ | + | |
- | x41z3.cluster.zone x41z4.cluster.zone x41z5.cluster.zone \ | + | |
- | x41z6.cluster.zone x41z7.cluster.zone x41z8.cluster.zone \ | + | |
- | x41z9.cluster.zone | + | |
- | </code> | + | |
- | === ''qconf -sql'' pour lister les queues de calcul === | ||
- | Pour lister toutes les queues, on applique la commande ''qconf -sql'' :<code> | + | ==== Lancer un calcul autonome (mode batch) ==== |
- | c6100 | + | |
- | r410 | + | |
- | x41z | + | |
- | </code> | + | |
- | === ''qconf -sq <Queue>'' pour détailler une queue === | + | Il est possible de lancer un batch en précisant les paramètres de soumission dans la commande en ligne mais il est de toutes façons nécessaire de créer un script shell. |
- | Pour lister toutes les queues, on applique la commande ''qconf -sq x41z'' :<code> | + | Autant créer un script de lancement Slurm lequel sera utilisé pour déclarer tout d'un bloc. |
- | qname x41z | + | |
- | hostlist @x41z | + | |
- | seq_no 0 | + | |
- | load_thresholds np_load_avg=1.75 | + | |
- | suspend_thresholds NONE | + | |
- | nsuspend 1 | + | |
- | suspend_interval 00:05:00 | + | |
- | priority 0 | + | |
- | min_cpu_interval 00:05:00 | + | |
- | processors UNDEFINED | + | |
- | qtype BATCH INTERACTIVE | + | |
- | ckpt_list NONE | + | |
- | pe_list sequential x41zhybrid | + | |
- | rerun FALSE | + | |
- | slots 8 | + | |
- | tmpdir /tmp | + | |
- | shell /bin/bash | + | |
- | prolog NONE | + | |
- | epilog NONE | + | |
- | shell_start_mode posix_compliant | + | |
- | starter_method NONE | + | |
- | suspend_method NONE | + | |
- | resume_method NONE | + | |
- | terminate_method NONE | + | |
- | notify 00:00:60 | + | |
- | owner_list NONE | + | |
- | user_lists NONE | + | |
- | xuser_lists NONE | + | |
- | subordinate_list NONE | + | |
- | complex_values NONE | + | |
- | projects NONE | + | |
- | xprojects NONE | + | |
- | calendar NONE | + | |
- | initial_state default | + | |
- | s_rt INFINITY | + | |
- | h_rt INFINITY | + | |
- | s_cpu INFINITY | + | |
- | h_cpu INFINITY | + | |
- | s_fsize INFINITY | + | |
- | h_fsize INFINITY | + | |
- | s_data INFINITY | + | |
- | h_data INFINITY | + | |
- | s_stack INFINITY | + | |
- | h_stack INFINITY | + | |
- | s_core INFINITY | + | |
- | h_core INFINITY | + | |
- | s_rss INFINITY | + | |
- | h_rss INFINITY | + | |
- | s_vmem INFINITY | + | |
- | h_vmem INFINITY | + | |
- | </code> | + | |
- | === ''qconf -spl'' pour lister tous les environnements parallèles === | + | === Lancer un batch séquentiel === |
- | Pour lister toutes les queues, on applique la commande ''qconf -spl'' :<code> | + | Le propre d'un programme séquentiel est que les commandes s'exécutent les unes derrière les autres. Dans le "vocable" de calcul scientifique, le //job séquentiel// s'exécute sur une machine et une seule, les tâches les unes à la suite des autres. |
- | r410hybrid | + | |
- | sequential | + | |
- | x41zhybrid | + | |
- | </code> | + | |
- | === ''qconf -sp <Environnement Parallèle>'' pour détailler un environnement parallèle === | + | Nous voulons exécuter le programme séquentiel ''HelloWorld'' sur une des machines de la zone cluster du CBP. |
+ | |||
+ | Nous voulons que le nom de fichiers de sortie soit préfixés de ''HelloWorld''. | ||
+ | |||
+ | Le lancement de batch se fait par : | ||
+ | <code>sbatch HelloWorld.slurm</code> | ||
+ | |||
+ | Le script de batch ''MyJob.slurm'' est le suivant : | ||
+ | <code> | ||
+ | #!/bin/bash | ||
- | Pour lister toutes les queues, on applique la commande ''qconf -sp x41zhybrid'' :<code> | + | srun date |
- | pe_name x41zhybrid | + | srun echo "Hello world!" |
- | slots 128 | + | srun date |
- | user_lists NONE | + | |
- | xuser_lists NONE | + | |
- | start_proc_args /bin/true | + | |
- | stop_proc_args /bin/true | + | |
- | allocation_rule 8 | + | |
- | control_slaves TRUE | + | |
- | job_is_first_task TRUE | + | |
- | urgency_slots min | + | |
- | accounting_summary TRUE | + | |
</code> | </code> | ||
- | ==== Connaître l'état des calculs en cours qstat ==== | + | Le lancement de batch se fait par : |
+ | <code>sbatch HelloWorld.slurm</code> | ||
- | === Pour connaître l'état général === | + | Il est possible de préciser dans le script de lancement de nombreuses informations notamment : |
+ | * le nom des sorties du terminal ''STDOUT'' et ''STDERR'' | ||
+ | * l'adresse de courriel d'expédition de message | ||
+ | * les ressources nécessaires à l'exécution | ||
+ | * l'usage exclusif d'une ressource (par exemple un noeud) | ||
- | <code>qstat</code> | + | L'ordonnanceur **slurm** dispose de centaines d'options pour paramétrer sa requête. |
- | === Pour avoir l'information sur une tâche particulière === | + | Le script de batch ''MyJob.slurm'' est le suivant : |
+ | <code> | ||
+ | #!/bin/bash | ||
+ | # | ||
+ | # Definition du nom du job, apparaissant dans la colonne NAME avec squeue : facultatif | ||
+ | #SBATCH --job-name=HelloWorld | ||
+ | # Definition du fichier de sortie (stdout) | ||
+ | #SBATCH --output=HelloWorld.out | ||
+ | # Definition du fichier de sortie des erreurs (stderr) | ||
+ | # | ||
+ | # Avec exclusive, le noeud est reserve dans sa totalite | ||
+ | #SBATCH --exclusive | ||
+ | # | ||
+ | #SBATCH --mail-type=END | ||
+ | #SBATCH --mail-user=mon.nom@mon-site.mon-pays | ||
- | Pour connaître toutes les informations sur la tâche 9, par exemple, ''qstat -j 9''<code> | + | srun date |
+ | srun echo "Hello world!" | ||
+ | srun date | ||
</code> | </code> | ||
- | On voit ainsi que la tâche a commencé le 5 février 2013 à 15h51 pour se terminer à 15h58 et qu'elle s'est exécutée sur 4 noeuds x41z. | + | <note important>Suite de la documentation en construction</note> |
- | ==== Lancer un calcul autonome (mode batch) ==== | + | === Réservation de ressources === |
- | Il est possible de lancer un batch en précisant les paramètres (queue, environnement parallèle, etc) mais il est nécessaire de toutes façons de créer un script shell. | + | Pour l'instant, la réservation de ressources n'est possible que sur les noeuds, les coeurs et la mémoire sur les clusters du CBP. |
- | Autant créer un script de lancement GridEngine lequel sera utilisé pour déclarer tout d'un bloc. | + | Voici un exemple de soumission slurm pour réserver un total de 64 coeurs sur un unique noeud |
- | === Lancer un batch séquentiel === | + | === Lancer un batch parallèle sur plusieurs coeurs === |
- | Le propre d'un programme séquentiel est qu'il ne peut pas se distribuer sur plusieurs noeuds. | + | Nous voulons exécuter le programme parallélisée ''MyJob'' sur 48 coeurs sur une machine de la queue **s92**. |
- | + | ||
- | Nous voulons exécuter le programme MPI ''MyJob'' sur 1 seul coeur, sur la queue des x41z. | + | |
Nous voulons que le nom de fichiers de de sortie soit préfixés de ''MyJob''. | Nous voulons que le nom de fichiers de de sortie soit préfixés de ''MyJob''. | ||
- | Le lancement de batch se fait par : | + | Nous créons le script suivant sous le nom (très original) de ''MyJob.slurm'' :<code> |
- | <code>qsub MyJob.qsub</code> | + | |
- | Le script de batch ''MyJob.qsub'' est le suivant : | ||
- | <code> | ||
- | # Nom du programme pour les sorties (sortie standard et sortie erreur Posix) | ||
- | #$ -N MyJob | ||
- | # Nom de la queue (ici, la queue des x41z) | ||
- | #$ -q x41z | ||
- | # Messages a expedier : il est expedie lorsqu'il demarre, termine ou avorte | ||
- | #$ -m bea | ||
- | # specify your email address | ||
- | #$ -M <prenom>.<nom>@ens-lyon.fr | ||
- | #$ -cwd | ||
- | #$ -V | ||
- | # Lancement du programme | ||
- | /usr/bin/time ./MyJob | ||
- | exit 0 | ||
</code> | </code> | ||
+ | |||
+ | Le programme se lance en utilisant la commande de soumission ''sbatch ./MyJob.slurm''. | ||
+ | |||
+ | La commande d'examen des tâches en cours ''squeue'' permet ensuite de savoir que le job a bien été pris en compte. | ||
+ | |||
+ | |||
=== Lancer un batch parallèle === | === Lancer un batch parallèle === | ||
Ligne 292: | Ligne 228: | ||
Nous voulons que le nom de fichiers de de sortie soit préfixés de ''MyJob''. | Nous voulons que le nom de fichiers de de sortie soit préfixés de ''MyJob''. | ||
- | Nous créons le script suivant sous le nom (très original) de ''MyJob.qsub'' :<code> | + | Nous créons le script suivant sous le nom (très original) de ''MyJob.slurm'' :<code> |
- | # Nom du programme pour les sorties (sortie standard et sortie erreur Posix) | + | |
- | #$ -N MyJob | + | |
- | # Nom de la queue (ici, la queue des x41z) | + | |
- | #$ -q x41z | + | |
- | # Nom de l'environnement parallèle avec le nombre de slots : x41zhybrid avec 32 ressources | + | |
- | #$ -pe x41zhybrid 32 | + | |
- | # Messages a expedier : il est expedie lorsqu'il demarre, termine ou avorte | + | |
- | #$ -m bea | + | |
- | # Adresse electronique d'expedition | + | |
- | #$ -M <prenom>.<nom>@ens-lyon.fr | + | |
- | #$ -cwd | + | |
- | #$ -V | + | |
- | /usr/bin/time mpirun.openmpi -np 32 -mca btl self,openib,sm ./MyJob | + | |
- | exit 0 | + | |
</code> | </code> | ||
- | Le programme se lance en utilisant la commande de soumission ''qsub ./MyJob.qsub''. | + | Le programme se lance en utilisant la commande de soumission ''sbatch ./MyJob.slurm''. |
- | La commande d'examen des tâches en cours ''qstat'' permet ensuite de savoir que le job a bien été pris en compte. | + | La commande d'examen des tâches en cours ''squeue'' permet ensuite de savoir que le job a bien été pris en compte. |