Exécuter une tâche

De Wiki de Calcul Québec
Aller à : Navigation, rechercher
Autres langues :anglais 100% • ‎français 100%

Sommaire

Principes généraux

Fonctionnement par tâches

Le plus souvent, en informatique, nous sommes familiers avec des environnements graphiques interactifs. Il y a des fenêtres, des menus, des boutons; on clique ici et là, et le système répond immédiatement. Sur les ordinateurs de Calcul Québec, c'est différent. Tout d'abord, l'environnement est en ligne de commande. Ensuite, les tâches demandées ne sont pas exécutées immédiatement, mais mises dans une file d'attente, ou queue. C'est seulement lorsque les ressources nécessaires sont disponibles que la tâche est exécutée, autrement les tâches se nuiraient les unes les autres. Il faut donc écrire un fichier (le script de soumission) qui décrit la tâche à exécuter et les ressources nécessaires, mettre la tâche dans la file d'attente, et revenir plus tard lorsque la tâche a terminé son exécution. Il n'y a donc pas d'interaction entre l'utilisateur et ses programmes pendant leur exécution.

C'est le rôle du système de soumission de tâches d'agir comme chef d'orchestre. Ses responsabilités sont multiples : il doit maintenir une base de données des tâches soumises jusqu'à leur exécution finale, faire respecter les politiques de lancement (limites, priorités), s'assurer d'assigner des ressources disponibles à une seule tâche à la fois, décider des tâches à exécuter et sur quels nœuds de calcul, gérer le lancement sur ces nœuds et rapatrier les sorties.

Sur les ordinateurs de Calcul Québec, ces responsabilités sont dévolues au logiciel Torque, combiné à un ordonnanceur qui décide quelles tâches exécuter. Nous utilisons les ordonnanceurs Maui et Moab, selon les serveurs.

Allocation de ressources

Sur un ordinateur personnel, il n'y a habituellement qu'un seul utilisateur à la fois, alors que des centaines d'utilisateurs peuvent se servir en même temps d'une grappe (le type d'ordinateur offert à Calcul Québec). Cette grappe est typiquement constituée de centaines de nœuds contenant de huit à 24 cœurs. Chaque utilisateur doit explicitement demander les ressources dont il aura besoin. Cela se spécifie principalement par deux paramètres : le temps d'exécution nécessaire pour compléter sa tâche et le nombre de processeurs (nombre de nœuds et de cœurs) sur lesquels il veut l'exécuter. Dans certains cas, on doit aussi spécifier la mémoire nécessaire pour permettre à l'ordonnanceur de choisir les nœuds les plus appropriés pour la tâche.

Il est important de bien spécifier ces paramètres. S'ils sont trop élevés, la tâche risque d'attendre plus longtemps en queue et de bloquer l'utilisation de la machine à d'autres utilisateurs qui pourraient en avoir besoin. S'ils sont trop petits, la tâche pourrait ne pas pouvoir s'exécuter au complet ou manquer de mémoire. Ce sont ces paramètres qui permettent à l'ordonnanceur de choisir les tâches en attente à exécuter.

Un exemple de fichier de soumission

La présente section décrit un exemple de fichier de soumission minimal. Le contenu exact du script variera selon les serveurs. Veuillez consulter la section « Documentation additionnelle spécifique aux serveurs » ci-dessous pour plus de détails.


Fichier : exemple_minimal.sh
#!/bin/bash
#PBS -A abc-123-aa
#PBS -l walltime=30:00:00
#PBS -l nodes=2:ppn=8
#PBS -q queue
#PBS -r n
 
module load compilers/intel/12.0.4
module load mpi/openmpi/1.4.5_intel
 
cd $SCRATCH/rep_travail
mpiexec /chemin/vers/mon/programme_mpi


Dans ce fichier, les lignes qui débutent par #PBS sont des options que l'on passe au gestionnaire de tâches. Les lignes qui commencent par # (mais pas #PBS ou #!) sont des commentaires, et seront ignorées. Les autres lignes forment le script qui roulera sur un des nœuds de calcul. Voici l'explication détaillée de ce fichier :

  • #!/bin/bash : cette ligne, qui doit être la première du fichier, indique qu'il s'agit d'un script interprété par /bin/bash. D'autres interpréteurs sont possible (« /bin/tcsh », « /bin/sh » ou même « /bin/env perl »).
  • #PBS -A abc-123-aa : on indique ici l'identificateur de projet (Rap ID). C'est obligatoire pour toutes les tâches de Colosse et Helios, et optionnel sur Briarée, Cottos, Guillimin et Hadès, avec le projet par défaut. Il sert à déterminer quelles ressources on peut allouer à la tâche et à comptabiliser les ressources utilisées au bon projet. Pour le moment, c'est inutile sur Mp2, Ms2 et Psi. Sur Colosse et Helios, on peut connaître son Rap ID à l'aide de la commande « serveur-info ».
  • #PBS -l walltime=30:00:00 : c'est le temps réel réservé pour la tâche, en heures, minutes et secondes. Après ce temps, Torque tue la tâche, qu'elle soit terminée ou non.
  • #PBS -l nodes=2:ppn=8 : c'est le nombre de nœuds et le nombre de cœurs par nœud (« ppn ») dont on a besoin.
  • #PBS -q queue : c'est la file d'attente à utiliser. Tous les serveurs définissent une file d'attente par défaut, de sorte que cette ligne n'est parfois pas nécessaire.
  • #PBS -r n : indique qu'on ne peut pas redémarrer la tâche. Certains serveurs considèrent par défaut qu'on peut la redémarrer en cas de panne, ce qui signifie que Torque peut la relancer du début. C'est à l'utilisateur de s'assurer qu'il peut redémarrer sa tâche sans effet secondaire indésirable.
  • module load compilers/intel/12.0.4 : on charge le compilateur Intel. Le nom du module varie d'une machine à l'autre.
  • module load mpi/openmpi/1.4.5_intel : on charge la bibliothèque MPI voulue (mettre celle que l'on a utilisé à la compilation du programme exécutable).
  • cd $SCRATCH/rep_travail : au début de l’exécution du script, le répertoire initial est le répertoire personnel de l'utilisateur ($HOME). On souhaite habituellement travailler dans un autre répertoire, typiquement dans un système de fichier approprié pour des gros fichiers (comme celui où se trouve $SCRATCH).
  • mpiexec /chemin/vers/mon/programme_mpi : on appelle ici le programme. Pour un programme MPI, la commande « mpiexec » s'occupe de lancer le processus sur tous les processeurs disponibles. Ici, on n'a pas précisé le nombre de processus à démarrer, mais la façon de lancer un programme MPI peut varier d'un serveur à l'autre.

Interaction avec le système de soumission de tâches

Soumission de la tâche

Après avoir écrit le script, on doit le soumettre à Torque. La commande pour ce faire est « qsub ». Sur Colosse, on utilise plutôt la commande de Moab appelée « msub ». L'exécution de cette commande imprime le numéro de la tâche si elle est mise en queue avec succès. En plus des options incluses dans le script avec la syntaxe #PBS, on peut donner des options à « qsub » et « msub » sur la ligne de commande. Les options données sur la ligne de commande ont préséance sur celles incluses dans le script.

Afficher la liste des tâches

La commande « qstat -a -u $USER » affiche la liste des tâches de l'utilisateur. Avec Maui et Moab, on peut faire « showq -u $USER ». Dans les deux cas, on enlève « -u $USER » pour voir les tâches de tout le monde.

Effacer ou tuer une tâche

Les commandes « qdel Numéro_de_tâche » (Torque) ou « mjobctl -c Numéro_de_tâche » (Moab) permettent d'effacer ou tuer une tâche. Le numéro de la tâche est celui affiché à la soumission et que l'on peut voir aussi avec « qstat » ou « showq ».

Rapatriement de la sortie standard et de la sortie d'erreur

L'affichage que l'on obtiendrait au terminal lors d'une exécution interactive s'écrit plutôt sous Torque dans des fichiers qui reviennent au répertoire de soumission à la fin de l'exécution de la tâche. Cherchez les fichiers avec les extensions .oNuméro_de_tâche (pour la sortie standard) et .eNuméro_de_tâche (pour la sortie d'erreur). Par exemple, tache_pbs.o99485 et tache_pbs.e99485. C'est là que l'on trouvera les résultats des simulations ainsi que les messages d'erreur si tout ne va pas comme prévu.

Si la tâche écrit un volume important de données à la sortie standard, il est préférable de rediriger la sortie standard dans un fichier :

mpiexec /chemin/vers/mon/programme_mpi > fichier.sortie

Priorité

La priorité des tâches est calculée selon le principe de « juste part ». Les tâches ne s'exécutent donc pas nécessairement dans l’ordre où elles sont soumises, l’ordonnanceur triant les tâches en tenant compte de la part du serveur qui devrait être attribuée à chaque groupe (basé sur l’allocation annuelle de chacun) ainsi que sur l’utilisation du serveur faite par ce groupe au cours du dernier mois. L’ordonnanceur tient également compte des ressources disponibles ainsi que du temps d’attente de la tâche, faisant en sorte que tous les calculs respectant les limites finissent par s'exécuter.

Puisque le nombre d’heures allouées à un groupe correspond en fait à une priorité de calcul, il sera toujours possible de calculer au-delà du nombre d’heures allouées. Nous nous réservons le droit de diminuer la priorité de calcul si un groupe calcule à une fréquence deux fois plus élevée que sa juste part sur une échelle de temps d'un mois. Nous appliquerons cette mesure en cas de trop forte demande des serveurs.

Autres références

Exemple de script avec documentation des options de qsub

Exemples de scripts pour simulations séquentielles multiples, tâches OpenMP, tâches hybrides

Exécuter une tâche en mode interactif

En cas de problème

Si vous n'arrivez pas à lancer votre tâche, veuillez nous fournir votre script, le nom du serveur et toute information nécessaire pour reproduire le problème. Nous aurons aussi besoin du numéro de la tâche si vous en avez obtenu un.

Documentation additionnelle spécifique aux serveurs

Briarée

Le système de soumission de tâches de Briarée est Torque accompagné de l'ordonnanceur Maui. On soumet une tâche avec la commande « qsub »:

[nom@serveur $] qsub [options] script.pbs


L'option « -A » servant à spécifier le projet (RAP Id) est optionnelle si vous n'avez qu'un seul projet actif ou un seul projet actif ayant une allocation. Si vous avez plusieurs projets actifs, vous pouvez définir un projet par défaut en l'écrivant dans le fichier $HOME/.projet. Si vous demandez un projet invalide, vos projets actifs s'afficheront.

Choix des nœuds de calcul

La mémoire disponible varie d'un nœud de calcul à l'autre sur Briarée. Tous les nœuds ont 12 cœurs, mais il y a 316 nœuds de 24 Go (2 Go par cœur), 314 nœuds de 48 Go (4 Go par cœur) et 42 nœuds de 96 Go (8 Go par cœur). On peut demander des nœuds de 48 Go en ajoutant à la requête la propriété m48G de la façon suivante : -l nodes=100:m48G:ppn=12. On peut aussi de la même façon spécifier la propriété m96G pour obtenir des nœuds de 96 Go et m24G pour obtenir des nœuds de 24 Go. Cependant, il n'est en général pas nécessaire de demander la propriété m24G car Maui teste la disponibilité des nœuds en ordre croissant de mémoire.

Il ne faut pas demander inutilement des nœuds de 48 Go ou 96 Go si une quantité de mémoire moindre suffit. Ce faisant, on risquerait d'empêcher d'autres tâches plus gourmandes d'occuper ces nœuds. De plus, on risquerait d'augmenter le temps d'attente de la tâche soumise.

Lorsque une tâche nécessite des nœuds de 96 Go, elle doit impérativement demander la propriété m96G pour avoir préséance sur les autres tâches sur ces nœuds.

Pour voir les ressources disponibles sur les nœuds de 24 Go, on utilise la commande suivante:

[nom@serveur $] pbs_free :m24G


et de même pour les nœuds de 48 Go et 96 Go en utilisant les propriétés m48G et m96G.

Queues

Il est inutile de spécifier la queue à la soumission. La queue par défaut est une queue de routage qui va aiguiller la tâche dans la bonne queue d'exécution selon le nombre de nœuds et le temps demandé. On peut voir les limites des différentes queues dans la table ci-dessous.

Queue Temps d'exécution maximum Nombre de nœuds minimum par tâche Nombre de nœuds maximum par tâche Nombre maximum de cœurs par utilisateur Nombre maximum de tâches par utilisateur Nombre maximum de cœurs pour toutes les tâches
test 1 h 1416
courte 48 h 4 72
normale 168 h (7 jours) 4 1416 36
longue 336 h (14 jours) 4 180 24 720
hpcourte 48 h 5 171
hp 168 h (7 jours) 5 171 2052 8

Aussi, un groupe ne peut avoir plus de 1416 tâches en exécution et ne peut utiliser plus de 2520 cœurs en même temps.

Les tâches demandant plus de quatre nœuds (48 cœurs) aboutissent dans les queues « hp » et « hpcourte ». Nous limitons l'accès à ces queues aux utilisateurs qui démontrent que leur modèle utilise les ressources efficacement. Contactez-nous pour plus de détails. De même, la queue « longue » n'est accessible qu'à ceux qui en font la demande.

Nous avons réservé quatre nœuds de 48 Go exclusivement à la queue « test », dans laquelle la tâche aboutit si elle demande une heure ou moins. Si ces quatre nœuds sont occupés, les tâches de la queue « test » peuvent aussi rouler sur d'autres nœuds, selon leur disponibilité.

Pour voir les ressources disponibles pour la queue « test », on utilise la commande suivante :

[nom@serveur $] pbs_free :test


Pour voir les ressources disponibles pour les queues autres que « test », on tape

[nom@serveur $] pbs_free :normal


Simulations multiples par nœud

Si un utilisateur lance 12 tâches séquentielles sur Briarée, Maui tentera de les regrouper sur un même nœud. De même pour des tâches parallèles demandant moins de 12 cœurs par nœud. Si ce n'est pas le comportement désiré, il faut demander des nœuds complets (ppn=12) ou spécifier une mémoire suffisamment grande pour que Maui ne mette qu'une tâche par nœud.

Seules des tâches d'un même utilisateur peuvent partager des nœuds.

Utilisation de MPI

Toutes les bibliothèques MPI disponibles sur Briarée utilisent la commande « mpiexec » pour exécuter un programme MPI. Si on veut lancer un processus pour chaque cœur obtenu de Torque, on n'a pas besoin de spécifier le nombre de processus ou la liste des nœuds à utiliser puisque « mpiexec » obtient ces renseignements directement de Torque :


Fichier : openmpi_briaree.sh
#!/bin/bash
#PBS -l walltime=30:00:00
#PBS -l nodes=2:ppn=12
#PBS -r n
 
 
module load intel-compilers/12.0.4.191
module load MPI/Intel/openmpi/1.6.2
 
 
cd $SCRATCH/rep_travail
mpiexec /chemin/vers/mon/programme_mpi

Colosse

Le système de soumission de tâches de Colosse est Torque accompagné de l'ordonnanceur Moab. On soumet une tâche avec la commande de Moab appelée « msub »:

[nom@serveur $] msub [options] script.pbs


L'option « -A » servant à spécifier le projet (RAP Id) est obligatoire, de même que les ressources de temps (-l walltime=) et de ressources de calcul (-l nodes=1:ppn=8).

Choix des nœuds de calcul

La mémoire disponible varie d'un nœud de calcul à l'autre sur Colosse. Tous les nœuds ont huit cœurs, mais il y a 936 nœuds de 24 Go (3 Go par cœur) et 24 nœuds de 48 Go (6 Go par cœur). On peut demander des nœuds de 48 Go en ajoutant l'option « -l feature='48g' » à la commande « msub ».

Il ne faut pas demander inutilement des nœuds de 48 Go si une quantité de mémoire moindre suffit. Ce faisant, on risquerait d'empêcher d'autres tâches plus gourmandes d'occuper ces nœuds. De plus, le temps d'attente est plus long pour ces nœuds compte tenu de leur petit nombre.

Limites temporelle et computationnelle

Une tâche sur Colosse peut durer au plus 48h. Le nombre maximum de noeuds disponibles pour une tâche est fonction de sa durée.

  • Pour une tâche durant au plus 24h, jusqu'à 32 noeuds peuvent être réservés.
  • Pour une tâche durant entre 24 et 48h, jusqu'à 16 noeuds peuvent réservés.

Queues

Il est inutile de spécifier la queue à la soumission. La queue par défaut est une queue de routage qui va aiguiller la tâche dans la bonne queue d'exécution selon le nombre de nœuds et le temps demandé.

Utilisation de MPI

Il faut charger le module correspondant à la version de la bibliothèque MPI désirée. La liste des versions disponibles sur Colosse s'obtient avec la commande

[nom@serveur $] module avail mpi


Avec OpenMPI, l'exemple de script de soumission donné dans la section générale ci-dessus fonctionnera très bien. Si on veut lancer un processus pour chaque cœur obtenu de Torque, on n'a pas besoin de spécifier le nombre de processus ou la liste des nœuds à utiliser puisque « mpiexec » obtient ces renseignements directement de Torque.


Réservation de la mémoire

Les nœuds de calcul sont dotés de 24 Go de mémoire vive, pour huit cœurs. On dispose donc de 3 Go par processus. Si pour une application particulière, les processus ont besoin de plus de 3 Go, il faut utiliser une fraction des cœurs disponibles en spécifiant à MPI le nombre de cœurs à utiliser. Par exemple, pour une tâche nécessitant 6 Go par processus, on pourrait utiliser le fichier de soumission suivant :


Fichier : openmpi_colosse_4coeurs.sh
#!/bin/bash
#PBS -A abc-123-aa
#PBS -l walltime=30:00:00
#PBS -l nodes=2:ppn=8
 
module load compilers/intel/12.0.4
module load mpi/openmpi/1.4.5_intel
 
mpiexec -npernode 4 /chemin/vers/mon/programme_mpi


Simulations multiples par nœud

Si un utilisateur lance huit tâches séquentielles sur Colosse, elles vont rouler sur des nœuds différents car une tâche obtient toujours des nœuds complets. Pour ne pas gaspiller les ressources, il faut regrouper plusieurs simulations dans une même tâche, si la mémoire le permet.

Cottos

Le système de soumission de tâches de Cottos est Torque accompagné de l'ordonnanceur Maui. On soumet une tâche avec la commande « qsub » :

[nom@serveur $] qsub [options] script.pbs


L'option « -A » servant à spécifier le projet (RAP Id) est optionnelle si vous n'avez qu'un seul projet actif ou un seul projet actif ayant une allocation. Si vous avez plusieurs projets actifs, vous pouvez définir un projet par défaut en l'écrivant dans le fichier $HOME/.projet. Si vous demandez un projet invalide, vos projets actifs s'afficheront.

Choix des nœuds de calcul

Tous les nœuds de calcul de Cottos sont identiques. Ils ont tous huit cœurs et 16 Go de mémoire vive (2 Go par cœur). On n'a donc pas besoin de choisir les nœuds.

Queues

Il est inutile de spécifier la queue à la soumission. La queue par défaut est une queue de routage qui va aiguiller la tâche dans la bonne queue d'exécution selon le nombre de nœuds et le temps demandé. On peut obtenir les limites des différentes queues à l'aide de la commande « qstat -q » exécutée sur cette machine.

Les tâches demandant plus de quatre nœuds (32 cœurs) aboutissent dans les queues « hp » et « hpcourte ». Nous limitons l'accès à ces queues aux utilisateurs qui démontrent que leur modèle utilise les ressources efficacement. Contactez-nous pour plus de détails.

Nous avons réservé deux nœuds exclusivement à la queue « test », dans laquelle la tâche aboutira si elle demande une heure ou moins. Si ces deux nœuds sont occupés, les tâches de la queue « test » peuvent aussi rouler sur d'autres nœuds, selon leur disponibilité.

Pour voir les ressources disponibles sur la queue « test », on utilise la commande suivante :

[nom@serveur $] pbs_free :test


Pour voir les ressources disponibles pour les queues autres que « test », on tape

[nom@serveur $] pbs_free :normal


Simulations multiples par nœud

Si un utilisateur lance huit tâches séquentielles sur Cottos, Maui tentera de les regrouper sur un même nœud. De même pour des tâches parallèles demandant moins de huit cœurs par nœud. Si ce n'est pas le comportement désiré, il faut demander des nœuds complets (ppn=8) ou spécifier une mémoire suffisamment grande pour que Maui ne mette qu'une tâche par nœud.

Seules des tâches d'un même utilisateur peuvent partager des nœuds.

Utilisation de MPI

Toutes les bibliothèques MPI disponibles sur Cottos utilisent la commande « mpiexec » pour exécuter un programme MPI. Si vous voulez lancer un processus pour chaque cœur obtenu de Torque, vous n'avez pas besoin de spécifier le nombre de processus ou la liste des nœuds à utiliser puisque « mpiexec » obtient ces renseignements directement de Torque :


Fichier : openmpi_cottos.sh
#!/bin/bash
#PBS -l walltime=30:00:00
#PBS -l nodes=2:ppn=8
#PBS -r n
 
module load intel-compilers/11.0.083
module load openmpi_intel64/1.4.1
 
cd $SCRATCH/rep_travail
mpiexec /chemin/vers/mon/programme_mpi

Guillimin

Le système de soumission de tâches de Guillimin est Torque accompagné de l'ordonnanceur Moab. On soumet une tâche avec la commande de Torque appelée « qsub »:

[nom@serveur $] qsub [options] script.pbs


On spécifie le projet à l'aide de l'option « -A abc-123-xy », où on remplace « abc-123-xy » par le RAP Id. Si cette option est absente, la tâche utilisera le projet par défaut.

Queues

Les nœuds de calcul de Guillimin sont regroupés en sept partitions :

  • Exécution sérielle (Serial Workload, SW) : pour des tâches séquentielles ou des tâches parallèles légères, mémoire: 3 Go/cœur.
  • Bande passante élevée (High Bandwidth, HB) : pour les tâches massivement parallèles, mémoire : 2 Go/cœur.
  • Grande mémoire (Large Memory, LM) : pour des tâches ayant besoin de beaucoup de mémoire (6 Go/cœur).
  • Exécution sérielle 2 (Serial Workload, SW2) : pour des tâches séquentielles ou des tâches parallèles légères, mémoire: 4 Go/cœur.
  • Grande mémoire 2 (Large Memory, LM2) : pour des tâches ayant besoin de beaucoup de mémoire (8 Go/cœur).
  • Extra Grande mémoire 2 (Extra Large Memory, XLM2) : pour des tâches ayant besoin de beaucoup plus de mémoire (12, 16 ou 32 Go/cœur).
  • Exécution accélérée (Accelerated Workload, AW2) : pour des tâches qui utilisent les GPUs ou les Intel Xeon Phis (4 ou 8 Go/cœur).

Les queues de Guillimin sont définies de façon flexible avec la queue par défaut (metaq). Selon le type de tâche, on la soumet en specificiant le nombre de coeurs (nodes et ppn ou procs) et la mémoire minimum par cœur (pmem).

La queue « debug » est une queue spéciale qui a été créée pour permettre aux utilisateurs de tester leur code avant de le soumettre pour une longue simulation. Les tâches que l'on soumet à cette queue devraient normalement démarrer rapidement, permettant de vérifier si le programme se comporte comme prévu. Cependant, les ressources disponibles dans cette queue sont limitées : la tâche ne peut rouler plus de deux heures (30 minutes si on ne spécifie pas le temps d'exécution). On ne peut obtenir qu'un maximum de quatre cœurs. Si l'utilisateur demande plus que ces limites, la tâche sera rejetée.

La queue « metaq » est la queue par défaut.


IMPORTANT :

  • Les nœuds de calcul associés aux sept partitions mentionnées ci-dessus ont des quantités de mémoire différentes. La tâche est mis sur un nœud selon le valuer du paramètre pmem (mémoire par cœur), par défault 1700m pour les tâches qui utilisent plusieur nœuds avec ppn=12, 2700m pour les tâches qui utilisent ppn<12 et 3700m pour pour les tâches qui utilisent ppn=16. La tâche sera tuée automatiquement si elle excède ces limites.
  • On peut aussi utiliser la queue par défaut « metaq » pour des tâches parallèles où il y a peu de communications entre les processeurs sans que ça pose de problème de performance. Cependant, si le programme échange beaucoup de données entre les nœuds (comme, par exemple, des FFT à trois dimensions parallélisées avec MPI), il faut alors utiliser la queue « hb » ou « lm » à la place.
  • Si le code utilise la parallélisation par fils (comme OpenMP), on doit specifier « nodes=1:ppn=m », car le programme n'échange pas de données entre les nœuds.
  • Il est toujours préférable de soumettre une tâche d'essai à la queue « debug » avant une longue simulation. L'utilisateur saura ainsi immédiatement si le programme fonctionne comme prévu ou non. Cependant, il ne faut pas utiliser la queue « debug » pour du travail de production car la tâche ne pourra rouler plus de deux heures et sera tuée automatiquement ensuite.
  • Le temps d'exécution par défaut des queues (sauf « debug ») est de trois heures. Le temps d'éxecution maximum que l'on peut spécifier est de 30 jours.

Simulations multiples par nœud

Plusieurs tâches peuvent rouler sur un même nœud si on specifie « nodes=1:ppn=m » avec m<12, d'un même utilisateur ou d'utilisateurs différents. Si ce n'est pas le comportement désiré, il faut demander des nœuds complets (ppn=12 ou ppn=16) ou spécifier une mémoire suffisamment grande pour que Moab ne mette qu'une tâche par nœud.


Utilisation de MPI

Voici un exemple de script de soumission pour une tâche MPI, qui va exécuter un programme sur 36 cœurs :


Fichier : openmpi_guillimin.sh
#!/bin/bash
#PBS -A abc-123-aa
#PBS -l walltime=30:00:00
#PBS -l nodes=3:ppn=12
#PBS -l pmem=5700m
 
module load ifort_icc/14.0.4
module load openmpi/1.6.3-intel
 
cd $PBS_O_WORKDIR
mpiexec -n 36 ./code


Les caractéristiques importantes de ce script de soumission sont les suivantes :

  • La ligne « #PBS -l nodes=3:ppn=12 » demande à Moab de réserver 36 cœurs sur 3 nœuds.
  • La ligne « #PBS -l pmem=5700m » demande à Moab de réserver 5.7G par cœur, donc la tâche doit rouler sur un nœud LM.
  • Les commandes « module load ... » chargent les modules correspondant au compilateur et à la bibliothèque MPI qui ont servi à compiler le programme. Sur Guillimin, on a accès à différentes versions de OpenMPI et Mvapich2. La commande « module avail » affiche les versions disponibles. Ces modules sont conçus pour utiliser automatiquement le réseau InfiniBand à haute vitesse. Il est déconseillé de tenter d'installer sa propre version de MPI.
  • La ligne « mpiexec -n 36 ./code » démarre le programme « code », compilé avec MPI, en parallèle sur 36 processus. La commande « mpiexec » organise toutes les communications entre les processus MPI. On ne devrait jamais demander plus de processus avec « -n » que de cœurs (nodes*ppn) avec « #PBS -l nodes=...:ppn=12 ». Si on ne spécifie pas le nombre de processus, la commande « mpiexec » va en lancer un par cœur.


Utilisation de ScaleMP

Sur Guillimin, nous avons configuré 11 nœuds à l'aide du logiciel ScaleMP pour qu'ils se comportent comme un seul ordinateur avec une grande mémoire partagée. Ces nœuds ont 12 cœurs et 8 Go de mémoire par cœur. Grâce à ScaleMP, on peut utiliser ces nœuds comme un nœud unique de 132 cœurs et 1 000 Go de mémoire. Ce système est donc très utile aux chercheurs ayant besoin de très grandes quantités de mémoire.

Tous les utilisateurs de Guillimin ont accès à la machine ScaleMP par l'intermédiaire de la queue « scalemp ». Voici comment à l'aide de l'exemple de script de soumission suivant, accompagné de la commande « qsub » correspondante :


Fichier : smpsubmit.bat
#!/bin/bash
#PBS -l nodes=1:ppn=16
#PBS -l walltime=0:10:00
# Pour associer les fils OpenMP à des cœurs consécutifs.
export KMP_AFFINITY=compact,verbose,0,0
export MKL_VSMP=1
cd $HOME/smpdir
export OMP_NUM_THREADS=16
 
./openmp-mm


[nom@serveur $] qsub -q scalemp ./smpsubmit.bat


Plusieurs exemples de programmes conçus spécifiquement pour ScaleMP se trouvent dans le répertoire « /software/ScaleMP/examples/ ». On peut copier ces programmes dans son répertoire personnel afin de les modifier, de les compiler et de les exécuter :


 
 [nom@serveur $] mkdir ScaleMPexamples
 [nom@serveur $] cp -R /software/ScaleMP/examples/* ScaleMPexamples/.
 


Ce répertoire contient des exemples pour différents types de tâches (séquentielles, MPI, OpenMP, MKL, pthreads, etc.) dans des sous-répertoires. Chaque sous-répertoire contient un exemple de script de soumission et des renseignements utiles. Il faut adapter l'exemple approprié pour le type de tâche que l'on veut rouler.

Hadès

Le système de soumission de tâches de la grappe Hadès est Torque accompagné de l'ordonnanceur Maui. On soumet une tâche avec la commande « qsub » à partir de briaree1, le nœud d'accès de Briarée, ou de hades, le nœud d'accès de Hadès. La commande

[nom@serveur $] qsub -q @hades -lnodes=1:ppn=3 -lwalltime=48:00:00 script.pbs


va donner trois GPU et trois cœurs. On peut utiliser huit cœurs sur un nœud si et ѕeulement si on demande le nœud au complet avec « -lnodes=1:ppn=7 ». Torque pense qu'il n'y a que sept cœurs par nœud.

L'option « -A » servant à spécifier le projet (RAP Id) est optionnelle si vous n'avez qu'un seul projet actif ou un seul projet actif ayant une allocation. Si vous avez plusieurs projets actifs, vous pouvez définir un projet par défaut en l'écrivant dans le fichier $HOME/.projet. Si vous demandez un projet invalide, vos projets actifs s'afficheront.

On peut aussi exécuter les commandes suivantes pour interroger Torque à propos de Hadès :


 
 [nom@serveur $] qstat -a @hades
 [nom@serveur $] pbsnodes -s hades
 [nom@serveur $] pbs_free hades
 


Avant la compilation (sur briaree1 ou le nœud d'accès hades) et l'exécution (dans votre script de soumission), il faut charger le module CUDA :


[nom@serveur $] module add CUDA



Choix des nœuds de calcul

Tous les nœuds de calcul de Hadès sont identiques. Ils ont tous huit cœurs, 24 Go de mémoire vive (3 Go par cœur) et sept GPU. On n'a donc pas besoin de choisir les nœuds.

Queues

Il est inutile de spécifier la queue à la soumission. La queue par défaut est une queue de routage qui va aiguiller la tâche dans la bonne queue d'exécution selon le nombre de nœuds et le temps demandé. On peut obtenir les limites des différentes queues à l'aide de la commande


[nom@serveur $] qstat -q @hades


exécutée sur hades ou briaree1.

Simulations multiples par nœud

Plusieurs tâches peuvent rouler sur un même nœud de Hadès, d'un même utilisateur ou d'utilisateurs différents. Si ce n'est pas le comportement désiré, il faut demander des nœuds complets (ppn=7) ou spécifier une mémoire suffisamment grande pour que Maui ne mette qu'une tâche par nœud. Comme les tâches se partagent les nœuds, il est primordial de n'utiliser que les ressources demandées, pas plus. Sinon, les tâches vont se nuire les unes les autres.

Utilisation de MPI

L'environnement logiciel de Hadès est le même que celui de Briarée. On y soumet donc des tâches MPI de la même façon. Pour des tâches MPI utilisant les processeurs graphiques (GPU), la seule différence est que l'on doit charger le module CUDA et que le programme doit être écrit en conséquence.

Helios

Paramètres obligatoires

Le système de soumission de tâches de Helios est Torque accompagné de l'ordonnanceur Moab. On soumet une tâche avec la commande de Moab appelée « msub »:

[nom@serveur $] msub [options] script.pbs


L'option « -A » servant à spécifier le projet (RAP Id) est obligatoire, de même que les ressources de temps (-l walltime=) et de ressources de calcul (-l nodes=X:gpus=Z). Notez en particulier que, pour éviter que deux usagers se partagent le même bus PCI, il est requis de demander des multiples de 2 GPU si vous demandez plusieurs GPU. Notez aussi que l'option ppn=z est interdite. Automatiquement, pour chaque paire de GPUs demandées, vous obtiendrez 5 cœurs (pour les noeuds K20) ou 3 coeurs (pour les noeuds K80).

Fichier : script_soumission.sh
#!/bin/bash
#PBS -N MaTache
#PBS -A abc-123-aa
#PBS -l walltime=300
#PBS -l nodes=1:gpus=2
cd "${PBS_O_WORKDIR}"


La commande « cd ${PBS_O_WORKDIR} » est nécessaire pour s'assurer que la tâche s'exécute dans le répertoire à partir duquel le script a été soumis.

Demande de GPUs

Le nombre de GPUs requis par nœud de calcul est spécifié via l'option -l nodes=x:gpus=y. Par exemple, la requête -l nodes=1:gpus=4 vous allouera un nœud ainsi que quatre GPUs et 10 processeurs sur ce nœud. Les nœuds d'Helios possèdent 8 GPUs et 2 processeurs de 10 cœurs chacun pour les nœuds K20, et 16 GPUs et 2 processeurs de 12 cœurs chacun pour les nœuds K80. Vous pouvez donc demander au maximum 8 GPUs pour un nœud K20, et 16 GPUs pour un nœud K80.

Durée maximale des tâches

La durée maximale des tâches de calcul est de 12 heures.

Fichiers de sortie et d'erreur par défaut

Sur Helios, les fichiers de sortie et d'erreur de la tâche sont définis par défaut aux ${MOAB_JOBID}.out et ${MOAB_JOBID}.err, dans le répertoire d'exécution de la tâche. Vous pouvez changer ces valeurs avec les options usuelles -o et -e.

Queue de soumission

Il n'est pas nécessaire de spécifier une queue de soumission sur Helios. La queue de soumission est déterminée automatiquement en fonction du temps (walltime) et du nombre de GPUs.

Nœuds K20 vs nœuds K80

Vous pouvez spécifier que vous désirez des nœuds équipés de GPUs K20 ou K80 avec l'option -l feature=k20 ou -l feature=k80. En l'absence de l'une de ces deux options, les tâches seront dirigées vers des nœuds équipés de K20 si la tâche demande plus de 1 GPU, et pourra s'exécuter sur l'un ou l'autre des types de nœuds pour les tâches d'un seul GPU.

helios-info

Sur Helios, la commande helios-info permet d'obtenir de l'information sur l'utilisation de votre groupe ainsi que sur l'utilisation globale de la grappe de calcul. Par exemple,

[nom@serveur $] helios-info 
 Your Rap IDs are: corem colosse-users exx-883-ac bwg-974-aa exx-883-ab exx-883-aa six-213-ad
Total number of jobs currently running: 28
Total number of k20 in use: 116/120 (96.00%).
Total number of k80 in use: 33/96 (34.00%).
You are currently using 0 k20 and 0 k80 for 0 job(s).
RAPI six-213-ad: 0 used GPUs / 0 allocated GPUs (recent history)

Mammouth parallèle II

Le système de soumission de tâches de Mp2 est Torque accompagné de l'ordonnanceur Maui. On soumet une tâche avec la commande « qsub » :

[nom@serveur $] qsub [options] script.pbs


On peut aussi soumettre les tâches à l'aide du logiciel bqTools. Ce dernier est utile pour soumettre d'un coup un très grand nombre de tâches. Un peu plus compliqué, mais offre beaucoup plus de fonctionalité que les PBS-Array.

Choix des nœuds de calcul

Sur Mp2, les nœuds de calcul diffèrent selon leur nombre de cœurs (24 ou 48), leur mémoire vive (32, 256 ou 512 Go) et la topologie de leur connexion au réseau Infinband. Le choix des nœuds se fait grâce à la queue de soumission.

Liste des queues

Queue Nombre de nœuds minimum Nombre de nœuds disponibles Mémoire vive par nœud Nombre de cœurs par nœud Temps d'exécution maximum Contention InfiniBand
qwork 1 (24 cœurs) 1588 32 Go 24 120 h 7:2
qfbb 12 (288 cœurs) 216 32 Go 24 120 h 1:1
qfat256 1 (48 cœurs) 20 256 Go 48 120 h 1:1
qfat512 1 (48 cœurs) 2 512 Go 48 48 h 1:1

La queue par défaut est « qwork ».

On exécute la commande « bqmon » pour savoir combien de nœuds sont libres dans chaque queue.

Exemples de soumissions

Étant donné le très grand nombre de cœurs, nous avons configuré Torque sur Mp2 de sorte qu'il ne voit qu'un seul cœur par nœud même s'il y en a plusieurs. Les tâches obtiennent donc toujours des nœuds complets. Par conséquent, seule la valeur « ppn=1 » est valide avec « qsub ». Les exemples suivants montrent quelles sont les ressources obtenues selon les paramètres passés à « qsub ».

La commande

[nom@serveur $] qsub -q qwork -l walltime=1:00:00 -l nodes=1:ppn=1 monscript.sh


donne un nœud (24 cœurs) à la tâche tandis que la commande

[nom@serveur $] qsub -q qfbb u-l walltime=1:00:00 -l nodes=12:ppn=1 monscript.sh


donne 12 nœuds (288 cœurs).

Pour des raisons de compatibilité, on peut utiliser les commandes de bqTools équivalentes suivantes avec « ppn=24 ». Celle-ci donne 24 cœurs :

[nom@serveur $] bqsub -q qwork -l walltime=1:00:00 -l nodes=1:ppn=24 monscript.sh


et celle-ci donne 288 cœurs :

[nom@serveur $] bqsub -q qfbb -l walltime=1:00:00 -l nodes=12:ppn=24 monscript.sh


Simulations multiples par nœud

Il ne faut pas utiliser « qsub » directement pour lancer plusieurs calculs séquentiels sur Mp2 dans des tâches différentes. On utiliserait alors qu'un cœur par nœud, ce qui gaspille les ressources. On doit regrouper plusieurs calculs séquentiels dans une même tâche. On peut le faire soi-même en écrivant le script de soumission en conséquence. On peut également utiliser les commandes « bqsub » ou « bqsub_accumulator » qui s'occupera d'accumuler automatiquement les calculs :


[nom@serveur $] bqsub -q qwork -l walltime=1:00:00 moncalculserie.sh



La commande « bqsubmit » accumule également les calculs séries en utilisant un calcul par cœur, par défaut. Deux nouvelles options ont été ajoutées à « bqsubmit » pour Mp2 (n'utilisez pas ces options sur Ms2):

Option Description Valeur par défaut
runJobsPerNode Nombre de calculs qui doivent être exécutés de façon concurrente. Cette option est utile si on lance des calculs OpenMp ou si on doit utiliser un plus faible nombre d'instances par nœud. Exemple: « runJobsPerNode=12 ». Nombre de cœurs du nœud
accJobsPerNode Nombre de calculs qui doit être accumulé par nœud. Cette option est utile si on roule un grand nombre de calculs durant un court laps de temps. Exemple: « accJobsPerNode=1000 ». Nombre de cœurs du nœud

Utilisation de MPI

On recommande les modules MPI « _ofed ». Par exemple :


[nom@serveur $] module add openmpi_pathscale64/1.4.3_ofed



[nom@serveur $] module add mvapich2_intel64/1.6_ofed


Comme Torque ne voit qu'un seul cœur par nœud alors qu'il y en a 24 ou 48, il est essentiel d'en tenir compte lors de la soumission des tâches. Par exemple, si on veut utiliser quatre cœurs par nœud, on roulerait une tâche utilisant OpenMPI de la façon suivante :


Fichier : openmpi_mp2.sh
#!/bin/bash
#PBS -N testOpenmpi
#PBS -l nodes=2
#PBS -l walltime=0:02:00
#PBS -q qwork@mp2
 
cd $PBS_O_WORKDIR
 
# le nombre de processus MPI par nœud *** il y a 24 cœurs par nœud
export ppn=4
export OMP_NUM_THREADS=$[24/ppn]
 
# le fichier exécutable
myExe=./a.out
 
# on démarre le programme
mpiexec -n $[PBS_NUM_NODES*ppn] -npernode $ppn $myExe >> stdout


On peut trouver d'autres exemples d'utilisation dans le répertoire « /opt/examples/mp2 » sur Mp2. Le sous-répertoire « mpi ». donne des exemples de scripts de soumission de programmes utilisant MPI avec les diverses bibliothèques disponibles sur Mp2. Le sous-répertoire « hybrid » donne des exemples de parallélisme hybride MPI-OpenMP avec les mêmes bibliothèques. Étant donné que chaque nœud possède 24 cœurs et une seule carte InfiniBand, il est souvent plus efficace de faire des calculs hybrides sur Mp2 que des calculs purement MPI. On peut demander conseil à un analyste pour plus de détails.

Mammouth série II

Le système de soumission de tâches de Ms2 est Torque accompagné de l'ordonnanceur Maui. On soumet une tâche avec la commande « qsub » :

[nom@serveur $] qsub [options] script.pbs


On peut aussi soumettre les tâches à l'aide du logiciel bqTools. Ce dernier logiciel est particulièrement utile pour faire de l'exploration de paramètres.

Choix des nœuds de calcul

La plupart des nœuds de la grappe Ms2 ont 16 Go de mémoire vive, à l'exception de 44 d'entre eux qui ont 32 Go. Tous les nœuds ont huit cœurs. Pour sélectionner un nœud à 32 Go, on peut ajouter la propriété « m32G » à la soumission. Par exemple :


[nom@serveur $] qsub -q work -l nodes=1:m32G,walltime=00:05:00 pbs1cores.sh


La topologie du réseau rapide InfiniBand de Ms2 est optimisée en bloc de 22 nœuds seulement. Pour un calcul qui requiert beaucoup de communications inter-nœud, il est préférable de s'assurer qu'il est confiné à l'intérieur d'un bloc. Pour ce faire, il faut choisir un des 14 blocs de Ms2, nommés t1s, t2s, ... t14s. Par exemple, pour utiliser deux nœuds du bloc « t3s », il faut spécifier « -l nodes=2:t3s:ppn=8 ».

Pour connaitre l'utilisation actuelle des blocs, on fait :


[nom@serveur $] bqmon|head -6;bqmon -p @ms |grep '^t[0-9]*s'


Liste des queues

Queue Nombre de nœuds minimum Nombre de nœuds disponibles Temps d'exécution maximum Mémoire vive
qwork 1 246 120 h 16 Go
qwork (m32G) 1 44 120 h 32 Go
qlong 1 6 1000 h 16 Go

La queue par défaut est « qwork ».

On exécute la commande « bqmon » pour savoir combien de nœuds sont libres dans chaque queue.

Simulations multiples par nœud

Si un utilisateur lance huit tâches séquentielles sur Ms2, Maui tentera de les regrouper sur un même nœud. De même pour des tâches parallèles demandant moins de huit cœurs par nœud. Si ce n'est pas le comportement désiré, il faut demander des nœuds complets (ppn=8) ou spécifier une mémoire suffisamment grande pour que Maui ne mette qu'une tâche par nœud.

Seules des tâches d'un même utilisateur peuvent partager des nœuds.

Au lieu de soumettre des tâches séquentielles indépendantes, on peut aussi demander un nœud complet et regrouper plusieurs calculs dans une tâche.

Une autre possibilité est d'utiliser la commande « bqsub_mono » pour accumuler des calculs sur huit cœurs avant de les soumettre. « bqsub_mono » utilise la même syntaxe que « qsub ». Par exemple :


 
 [nom@serveur $] bqsub_mono -q qwork@ms -l nodes=1:ppn=8,walltime=00:05:00 pbs1core_1.sh
 [nom@serveur $] bqsub_mono -q qwork@ms -l nodes=1:ppn=8,walltime=00:05:00 pbs1core_2.sh
 [nom@serveur $] bqsub_mono -q qwork@ms -l nodes=1:ppn=8,walltime=00:05:00 pbs1core_3.sh
 [nom@serveur $] bqsub_mono -q qwork@ms -l nodes=1:ppn=8,walltime=00:05:00 pbs1core_4.sh
 


et ainsi de suite. Si le nombre de calculs accumulés avec « bqsub_mono » n'est pas un multiple de huit, les calculs restants seront lancés quand même après 15 minutes.

Utilisation de MPI

Vous devez tout d'abord choisir la version de MPI désirée à l'aide de la commande « module » :


 
 [nom@serveur $] module add mvapich2_intel64
 [nom@serveur $] module initadd mvapich2_intel64
 


pour ensuite compiler votre programme écrit en MPI avec la commande :


[nom@serveur $] mpicc calc_pi.c -o calc_pi


Vous lancerez finalement votre calcul avec un script PBS ou avec la commande « bqsub ». Voici un exemple de calcul soumis sur deux nœuds, avec huit processus par nœud :


[nom@serveur $] bqsub -q qwork@ms -P "applicationType=mpi" -P "command=./calc_pi" -l nodes=2:ppn=8 -l walltime=00:10:00


ou


[nom@serveur $] qsub -q qwork@ms -l nodes=2:ppn=8,walltime=00:10:00 calc_pi.sh

Psi - (archives)

Le système de soumission de tâches de Psi est Torque accompagné de l'ordonnanceur Maui. On soumet une tâche avec la commande « qsub » :

[nom@serveur $] qsub [options] script.pbs


Choix des nœuds de calcul

Tous les nœuds de calcul de Psi sont identiques. Ils ont tous 12 cœurs et 72 Go de mémoire vive (6 Go par cœur). On n'a donc pas besoin de choisir les nœuds.

Queues

Il n'y a qu'une seule queue sur Psi. Comme elle est définie comme queue par défaut, on n'a jamais besoin de la spécifier.

Simulations multiples par nœud

Plusieurs tâches peuvent rouler sur un même nœud de Psi, d'un même utilisateur ou d'utilisateurs différents. Si ce n'est pas le comportement désiré, il faut demander des nœuds complets (ppn=12) ou spécifier une mémoire suffisamment grande pour que Maui ne mette qu'une tâche par nœud.

Utilisation de MPI

Des exemples de scripts de soumission se trouvent dans le répertoire « /export/home/SCRIPTS » sur Psi.


Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Ressources de Calcul Québec
Outils
Partager