Exécuter une tâche
• 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.
#!/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
