Calculateur CEMAG//Gestionnaire de tâches
Dernière mise à jour 12-05-2010 17:16 / Jean-François RabasseRetour rubrique Calculateur CEMAG
Planificateur de tâches
Le logiciel rplan est installé sur le calculateur Altix. Cet outil permet d'établir le planning d'utilisation de la machine sur une durée indéterminée, semaine, mois, trimestre, sous forme d'allocations de ressources. Chaque utilisateur autorisé se voit attribuer un ou plusieurs slots sous forme d'une réservation nombre de CPU x durée.
La planification des slots est faite par un administrateur sur une base de négociations (réunion du jeudi matin). Chaque slot est la propriété exclusive de son bénéficiaire qui seul pourra y soumettre des tâches.
La répartition courante est consultable en ligne, voir Allocations.
Sommaire
Présentation du programme
Le gestionnaire se compose d'un seul programme, rplan :
rplan <commande> [arguments]
Ce programme dispose, en ligne, d'une aide générale sur les commandes, avec les options les plus usuelles :
rplan help
ou d'une aide contextuelle, spécifique à une commande, donnant la liste de toutes ses options. Par exemple :
rplan help submit rplan help slots
NB: le système d'aide de rplan n'est pas un simple affichage de texte mais est généré par du code qui utilise les tables internes de l'analyseur de commandes et options. De fait, cette aide est nécessairement correcte et exhaustive. Cette documentation web est, elle, maintenue à la main. Elle ne peut être garantie sans erreurs ou ommissions. En cas de désaccord, c'est le help en ligne qui fait foi.
Le programme rplan continue à utiliser pbs comme gestionnaire de queue mais certaines commandes pbs ne doivent plus être utilisées telles quelles (elle sont d'ailleurs désactivées). Ceci concerne les commandes qsub, qhold, qrls.
Il convient d'utiliser les équivalents rplan à la place, ou les commandes abrégées.
Soumission de tâches
Soumission d'un script
La soumission sous sa forme la plus simple se fait via la commande :
rplan submit <nom-du-script>
ou, sous forme abrégée :
rplan sub <nom-du-script>
Options
Une seule option de soumission est reconnue et traitée par rplan, c'est la spécification du numéro de slot dans lequel la tâche doit être lancée. Par défaut c'est le premier slot appartenant à l'utilisateur et de taille convenable pour cette tâche (nombre de processeurs et durée).
Dans le cas d'un utilisateur disposant de plusieurs slots, il est possible d'en spécifier un en particulier, e.g. :
rplan submit -s 1234 <nom-du-script> .. autres options
Toutes les autres options sont des options PBS.
Options PBS
rplan accepte toutes les options utilisables par l'ancien outil qsub, options qui peuvent être spécifiées indifféremment en ligne de commande ou placées à l'intérieur du script sous la syntaxe habituelle. Par exemple, pour spécifier le nombre de CPU nécessaires à la tâche, on pourra lancer :
rplan sub -l ncpus=16 <nom-du-script>
ou bien :
rplan sub <nom-du-script>
en ayant écrit dans le script :
#PBS -l ncpus=16
Deux options sont obligatoires, en ligne de commande ou dans le script, ce sont le nombre de processeurs nécessaires, ncpus=NN, et la durée du job, walltime=HH:MN:SS
rplan refusera toute soumission ne spécifiant pas ces deux options. Il n'est donc plus possible de lancer quoi que ce soit sans walltime.
Spécificités des scripts pour rplan
Les scripts de soumission indiqués par les utilisateurs ne sont pas utilisés en l'état. Lors du lancement effectif de la tâche, rplan les reconstruits avant de les injecter dans le système pbs. Cette reconstruction porte sur les options et aussi sur la réécriture complète des lignes de lancement du programme, en particulier pour pouvoir spécifier les placements sur les processeurs et les sélections multi noeuds.
Pour identifier la ligne du script qui lance effectivement le programme, rplan examine la toute première commande de chaque ligne du script et, dans sa version actuelle, reconnaît quatre commandes (lanceurs) : time, nice, mpirun et rwrap.
Sur cette base, la ligne de lancement est analysée et sera entièrement reconstruite dans le script définitif. Ces deux scripts, l'original présenté par l'utilisateur et le script reconstruit pour exécution, sont conservés dans un répertoire spécifique /var/spool/rplan/tmp.
Le script original est nommé script-NNNN.USER et le script reconstruit submit-NNNN.USER où NNNN est l'identifiant rplan de la tâche et USER est le nom de l'utilisateur.
Par exemple, voici un script de soumission, en syntaxe minimum :
#!/bin/bash # #PBS -l ncpus=160 #PBS -l walltime=1:00:00 cd $HOME/Soft/torque mpirun ./testsig -a 1800 echo "Done..."
et le même script, reconstruit par rplan tel qu'il sera effectivement lancé sous le gestionnaire de queue PBS :
#!/bin/bash # # Rplan V 3.5.1 submission script for task 2160 in slot 1703 # This script is for the Torque batch system. # Username...... rabasse # Script file... /home/rabasse/Soft/torque/Test2 # Generated..... 2008/01/07 10:51 # Warning ! Do not edit this script, modifications would be lost ! # #PBS -N Test2 #PBS -o /home/rabasse/Soft/torque/Test2.o2160 #PBS -e /home/rabasse/Soft/torque/Test2.e2160 # #PBS -l walltime=1:00:00 #PBS -l ncpus=160 #PBS -l nodes=1:jxb01:ppn=64+1:jxb02:ppn=64+1:jxb03:ppn=32 # cd $HOME/Soft/torque # -- Rplan rebuilt command for program "./testsig" : mpirun -a jxb \ . jxb01 64 rwrap -iCS2160.rp -s1 -- ./testsig -a 1800 \ . : jxb02 64 rwrap -iCS2160.rp -s1 -- ./testsig -a 1800 \ . : jxb03 32 rwrap -iCS2160.rp -s1 -- ./testsig -a 1800 echo "Done..."
Toutes les spécifications de noeuds de calcul, nombre de CPU, placement des CPU, sont entièrement prises en charge par rplan. À remarquer que rplan insère l'appel d'un lanceur spécialisé, rwrap, assurant la gestion de cpusets et de placement processeurs pour la tâche lancée. Voir Le lanceur de tâches rwrap.
NB: le script utilisateur est lu une seule fois lors de la soumission (rplan sub ...). Il n'est plus possible de le modifier ensuite, même si la tâche n'a pas encore démarré. Le seul moyen de changer après coup une option est de tuer la tâche planifiée puis de resoumettre le script modifié.
Programmes MPI purs
Par rapport à un script destiné à l'ancien qsub, les lignes de lancement de programmes MPI peuvent être simplifiées. En particulier le nombre de processeurs, option mpirun -np <nn>, n'est plus utile puisque la réécriture du script le définira en accord avec le nombre de CPU demandés via l'option de soumission ncpus=NN. La cohérence est assurée de fait.
Si le programme MPI doit tourner sur plusieurs noeuds du cluster Altix, rplan reconstruira la commande mpirun complète, avec les spécifications d'hôtes et de CPU, ainsi que des options de placement par défaut, comme -s1. (Cf. exemple de script ci-dessus).
Il en résulte que l'écriture minimum d'un lancement de programme MPI peut se limiter à :
mpirun myprog.exe
Programmes OpenMP purs
La ligne de lancement du programme devra obligatoirement commencer par une commande nice ou time ou rwrap permettant sa reconnaissance. Par exemple :
time omptest.exe
ou :
rwrap omptest.exe
Plus, bien sûr, les spécifications de ressources, nombre de processeurs et walltime.
Il est également utile d'utiliser l'option select de pbs, pour indiquer que la tâche doit impérativement tourner sur un seul noeud de calcul et non à cheval sur deux noeuds. Par exemple :
#!/bin/bash # #PBS -l ncpus=32 #PBS -l walltime=24:00:00 #PBS -l select=1 rwrap omptest.exe
À défaut, on pourra également reconfigurer la tâche soumise sous rplan via l'option -o, voir Gestion des tâches, ou mieux, utiliser des slots déjà configurés avec cette option noeud unique.
Par défaut, rplan reconstruira la ligne de lancement via l'utilisation du programme lanceur rwrap, sans faire aucun placement (option -z de rwrap). Si l'on souhaite spécifier des options de placement de processus, on devra alors utiliser explicitement la command rwrap avec les options requises, par exemple :
rwrap -x2 omptest.exe
Programmes mixtes MPI OpenMP
Un peu analogue aux tâches purement OpenMP au détail près qu'il faudra limiter le nombre de processus MPI en utilisant l'option standard de mpirun, -np Le nombre de processeurs demandés pour la tâche sera la somme des processus MPI et des threads OpenMP.
À première vue (point à investiguer) il semble préférable de ne pas faire de placements sur les processeurs. L'option -z de rwrap sera utilisée.
Par exemple, une tâche à 40 processeurs, 8 MPI et 32 threads OpenMP, sera lancée par un script de ce type :
# ... #PBS -l ncpus=40 #PBS -l select=1 mpirun -np 8 rwrap -z ./program.exe
Dans l'état actuel de rplan, les tâches hybrides doivent être exécutées sur un seul noeud de calcul (d'où la directive select=1). Le support multi noeuds va arriver bientôt.
Commandes abrégées
Certaines commandes de rplan, d'usage courant, sont disponibles sous forme simplifiée via des alias copiant, à la lettre initiale près, les principales commandes du système pbs.
On les utilisera en ajoutant les arguments et options ad-hoc, par exemple :
rsub -s 1234 toto.script
au lieu de :
rplan submit -s 1234 toto.script
Liste des alias
| rsub | Alias de : rplan submit |
| rdel | Alias de : rplan task -kill |
| rstat | Alias de : rplan tasks |
| rhold | Alias de : rplan task -h + |
| rrls | Alias de : rplan task -h - |
Gestion des tâches
La commande :
rplan tasks [options]
affiche l'état courant des tâches. Par défaut ne sont affichées que les tâches appartenant à l'utilisateur qui lance la commande. L'option -a (pour all) permet d'afficher toutes les tâches en cours et l'option -u <user> toutes les tâches appartenant à un utilisateur donné.
Exemple (l'affichage est découpé en deux blocs pour tenir en largeur) :
Task ID PBS ID Slot Owner Jobname CPU N W Time Pr S ./. ------- ----------- ---- -------- ----------- --- - ------ -- - ./. 1815.rp 4445.jxb00 1322 hennebel RAMSES_MHD 64 1 72:00 50 R ./. 1837.rp 4464.jxb00 1765 ludovic job_paro3 16 1 30:00 50 R ./. 1847.rp 4474.jxb00 1765 gissinge bem65 16 1 20:00 50 R ./. 1817.rp 4446.jxb00 1768 hennebel RAMSES_MHD 64 1 70:00 50 R ./. 1851.rp (waiting) 1703 rabasse Test160 160 - 24:00 50 P ./. ./. Sched/Start Elaps. ./. ------------ ------ ./. 16-15:51 64:51 ./. 18-15:00 17:42 ./. 18-17:00 15:42 ./. 16-15:56 64:47 ./. 01/02-08:00 -
Informations
| Task ID | Identifiant rplan de la tâche. L'extension .rp est optionnelle lorsqu'on référence la tâche. |
| PBS ID | Identifiant pbs de la tâche lorsqu'elle a été démarrée. Les tâches planifiées mais non encore lancées apparaissent avec la mention (waiting). |
| Slot | Identifiant du slot dans lequel la tâche a été soumise. |
| Owner | Propriétaire de la tâche. |
| Jobname | Nom du job au sens pbs, i.e. défini par l'option -N xxxx. |
| CPU | Nombre de processeurs demandés/alloués. |
| N | Single node mapping. Il s'agit d'un flag; la valeur 1 signifie que la tâche doit être planifiée sur un seul noeud de calcul et ne doit pas chevaucher une frontière de noeuds. (Cas typique des programmes OpenMP.) |
| W Time | Temps maximum demandé/alloué, ou walltime, affiché en heures:minutes. |
| Pr | Priorité de la tâche. Analogue au nice Unix, la valeur par défaut est 50 et peut être modifiée de plus ou moins 20. |
| S | État de la tâche. Les états usuels sont R pour une tâche en cours d'exécution, P pour une tâche planifiée non encore démarrée, H pour une tâche mise en attente par l'utilisateur, W pour une tâche mise en attente par rplan parce qu'elle ne peut être planifiée pour le moment, en général parce que le slot qui la contient est trop court en temps. Elle pourra être planifiée ultérieurement lorsque des tâches qui précédent durent moins longtemps que prévu. |
| Sched/Start | Date de démarrage prévue (pour une tâche en état P) ou effective (pour une tâche en état R). |
| Elaps. | Temps écoulé, pour une tâche en état R. |
Reconfiguration
Une tâche lancée, via rplan submit, peut à tout moment être reconfigurée via la commande :
rplan task <taskid> [options...]
La liste des options disponibles est accessible par la commande :
rplan help task
Formats de temps
Pour les options qui demandent un argument de durée ou de date, rplan utilise les formats suivants :
Les durées doivent être spécifiées en heures.minutes ou jours.heures.minutes sous forme d'une suite de valeurs séparées par des caractères non numériques. N'importe quel séparateur est admis.
Par exemple, pour (re)configurer le walltime d'une tâche à 2 jours et 12 heures, on pourra utiliser les notations :
rplan task <taskid> -t 2.12.0
ou :
rplan task <taskid> -t 60:0
Les dates suivent le même principe et doivent être spécifiées au minimum par jour.heure.minute, ou mois.jour.heure.minute, ou année.mois.jour.heure.minute. Si le mois n'est pas spécifié, ce sera implicitement le mois en cours sauf si le jour spécifié est avant le jour courant, auquel cas le mois sera le mois suivant. Même chose pour les mois et années.
Valeurs booléennes
Quelques options, -o, -h, -x, demandent un argument de nature booléenne. Rplan accepte diverses notations usuelles pour spécifier des booléens, yes/no ou y/n, true/false ou t/f, 1/0 ou plus généralement tout numérique non nul vs. nul, et enfin +/-.
Options de (re)configuration
| -n <total-cpus> | Redéfinition du nombre de processeurs demandés. Ne peut être effectué que sur une tâche non encore démarrée. |
| -t <total-time> | Redéfinition du walltime. Peut être effectuée sur une tâche planifiée mais aussi sur un tâche démarrée. Dans ce dernier cas une commande qalter sera émise vers le système de batch. |
| -a <start-date> | Spécification d'une date de départ de tâche, prise en compte pour la planification. |
| -e <end-date> | Définition d'une date de fin de tâche. Attention, il ne s'agit nullement d'une spécification de planification, comme la date de départ, mais d'une alternative pour redéfinir le walltime. Toute tâche planifiée ou en exécution dispose d'une date de départ prévu ou effectif, cette option permet de recalculer le walltime par différence. |
| -o <bool> | Single node mapping mode. Ce mode, si le booléen est vrai, impose que la tâche doivent s'exécuter sur un seul noeud du cluster, sans chevaucher une frontière de machine. Cas typique des programmes OpenMP. |
| -d <taskid> | Spécification d'une dépendance de placement. La tâche reconfigurée ainsi devra démarrer après la tâche argument <taskid>. Il s'agit de l'ordre de planification uniquement, non d'une dépendance départ de tâche après la fin de l'autre. Cette option sert essentiellement à réorganiser l'ordre des tâches d'un slot s'il n'est pas satisfaisant. |
| -s <slotid> | Déplace la tâche dans un autre slot. L'opération n'est effectuée que si elle est possible (taille de la tâche, durée, autorisations sur le slot). |
| -p <nice-level> | Définition de la priorité de la tâche. Fonctionne comme le nice Unix. Les tâches ont une priorité par défaut de 50. On augmente la priorité en spécifiant une valeur négative, de -1 à -20, on baisse la priorité en spécifiant une valeur positive, de 1 à 20. Cette option sert essentiellement à réorganiser l'ordre des tâches d'un slot, en particulier en forçant des petits jobs à passer avant des plus gros, alors que l'algorithme de planification de rplan a tendance à favoriser les gros. |
| -h <bool> | Active ou désactive la suspension d'une tâche (hold mode. Une tâche en suspend apparaît dans un état H, dans la liste des tâches, mais n'est pas prise en compte dans la planification et ne sera jamais lancée sauf à désactiver son état. |
| -r | Supprime la tâche du slot si elle n'est pas encore démarrée. |
| -kill | Supprime la tâche dans tous les cas, planifiée ou démarrée. Si la tâche est déjà en exécution, une commande qdel sera émise vers le système de batch. |
| -x <bool> | Active ou désactive le mode expansion sur la tâche. Ce mode est destiné à utiliser au mieux le temps de slot disponible. Lorsqu'on planifie une série de tâches successives, avec des walltime raisonnables, il peut arriver que certaines durent moins longtemps que prévu. Une tâche en mode expansion va, lors de son démarrage, recalculer son walltime dynamiquement, en fonction du temps de slot restant, pour occuper tout l'espace disponible. Ce mode doit évidemment n'être activé que sur la dernière tâche d'un slot, aucune planification ultérieure ne sera possible. |
| -si <snum> <mins> | Spécification d'un signal de fin de tâche. Cette option est utile pour les programmes écrits pour gérer certains signaux Unix et devant faire des opérations longues avant de s'arrêter, typiquement de grosses écritures de données. Àprès la soumission d'une tâche lançant un tel programme, on pourra la reconfigurer pour, par exemple : rplan task <taskid> -z 10 5 envoyer le signal 10 au programme, 5 minutes avant la fin. Attention, dans le cas d'un programme MPI, le signal sera transmis via le système de batch (qsig de PBS) au processus père, i.e. mpirun. L'implémentation SGI de mpirun filtre les signaux Unix reçus sauf deux qui sont transmis à tous les process enfants et qui sont le 10 et le 23. Tous les autres signaux n'atteindront jamais les enfants. |
Gestion des slots
La commande :
rplan slots [options]
permet d'afficher l'état courant des slots. Par défaut ne sont affichées que les slots appartenant à l'utilisateur qui lance la commande. L'option -a (pour all) permet d'afficher tous les slots en cours et l'option -u <user> tous les slots appartenant à un utilisateur donné.
Exemple (l'affichage est découpé en deux blocs pour tenir en largeur) :
Slot ID Owner CPU W Time Cost Eu Max wt N Start at Pr S D ./. ------- -------- --- ------ ------- ------ - ------------ -- - - ./. 1322.rp hennebel 64 725:47 15120 - - - 50 R - ./. 1765.rp ludophe 32 233:44 2435 - 1 - 50 R - ./. 1768.rp hennebel 128 515:23 21474 - - - 50 R - ./. 1703.rp rabasse 256 60:00 5000 - - 01/02-08:00 30 P - ./. ./. Sched/Start Elaps. ./. ------------ ------ ./. 11/19-18:12 710:32 ./. 10-18:16 206:28 ./. 11-20:36 180:08 ./. 01/02-08:00 -
Informations
| Slot ID | Identifiant rplan du slot. L'extension .rp est optionnelle. |
| Owner | Propriétaire du slot. Ce peut être un utilisateur réel ou le nom d'un groupe. |
| CPU | Nombre de processeurs demandés/alloués. |
| W Time | Temps maximum demandé/alloué, ou walltime. |
| Cost Eu | Coût du slot, en Euros. Il s'agit d'une valeur indicative, établie à partir de la taille du slot, nombre de processeurs et durée, et du coût consolidé du calculateur. Le but de cette information est d'aider à la prise de conscience de ce que coûte (au contribuable français) un slot demandé et non utilisé. (Une future version de rplan déduira automatiquement les coûts de slots non utilisés des salaires ou bourses de thèse des utilisateurs.) |
| Max wt | Temps maximum autorisé pour les tâches soumises dans ce slot. Utile seulement dans le cas de slots administratifs, jobs courts, etc. |
| N | Single node mapping. Il s'agit d'un flag similaire à celui concernant les tâches. La valeur 1 indique que le slot est à planifier sur un seul noeud de calcul, sans chevaucher une frontière de noeuds. Pour les utilisateurs de programmes OpenMP, il est plus confortable de demander un slot en mode single node plutôt que de devoir respécifier pour chaque tâche soumise. |
| Start at | Date de démarrage différé du slot, prise en compte par la planification. |
| Pr | Priorité du slot. Analogue aux tâches. |
| S | État du slot. Les états usuels sont R pour un slot démarré, P pour un slot planifié non encore démarré, H pour un slot mis en attente. |
| D | Drop mode. Option d'un slot qui fait que lorsque la dernière tâche contenue se termine, le slot se termine également, même s'il lui reste du temps. Les slots planifiés derrière lui pourront alors avancer plus tôt que prévu. Ce mode est activé par l'option -r, remove when empty. |
| Sched/Start | Date de démarrage prévue (pour un slot en état P) ou effective (pour un slot en état R). |
| Elaps. | Temps écoulé, pour un slot en état R. |
Reconfiguration
Les slots peuvent être reconfigurés via la commande :
rplan slot <slotid> <options...>
La liste des options disponibles est accessible par la commande :
rplan help slot
Les options sont similaires aux options de reconfiguration des tâches. La différence majeure vient des valeurs autorisées pour les paramètres intervenants dans la planification, à savoir nombre de processeurs, durée, priorité. Pour les slots, l'utilisateur non administrateur ne peut que modifier à la baisse les valeurs. Il n'est pas possible d'agrandir son slot pour occuper tout le cluster pendant six mois.
Options particulières aux slots
| -l | Option d'affichage, analogue aux commandes rplan slots ou rplan tasks, mais limitée au slot argument et à toutes les tâches qu'il contient. |
| -u <user> | Permet de "donner" son slot à un autre utilisateur. Cela fait partie des arrangements entre individus lorsqu'un utilisateur réalise qu'il ne va plus utiliser tout son temps alloué. |
| -r | À la différence du "remove" tâche, acitf uniquement sur une tâche non en exécution, le "remove" slot appliqué à un slot en exécution signifie : détruire dès qu'il sera vide, i.e. la dernière tâche est terminée. C'est le drop mode indiqué plus haut. Cette option est utile dans le cas de tâches dont le walltime a été surestimé par sécurité mais que l'utilisateur souhaite rendre la place disponible dès que possible, sitôt sa dernière tâche achevée. (Voir paragraphe suivant.) |
| -mt <time> | Spécification du walltime maximum des tâches pouvant être lancées dans ce slot. Option d'administration, permettant de créer des slots communautaires réservés à des tâches courtes. |
Du bon usage des slots
L'outil rplan n'est pas un substitut à pbs mais un complément. C'est un planificateur de tâches alors que pbs est un gestionnaire de queues.
Un gestionnaire de queues est surtout orienté utilisation optimale d'un cluster et travaille autour d'une logique "lorsque quelque chose s'arrête, que peut-on lancer pour ne pas laisser de processeurs inoccupés". L'utilisation des ressources est optimale mais cette stratégie présente quelques inconvénients, en particulier pour notre utilisation :
Difficulté à passer de gros jobs, due au fait qu'un gros job ne peut démarrer que s'il existe un "trou" suffisament grand, lequel a rarement le temps de se développer tant qu'il existe de plus petits jobs en attente.
Difficulté ou impossibilité de faire du travail de mise au point, caractérisé par des runs courts suivis de temps d'arrêt pour corrections. Les temps d'arrêt sont exploités par le gestionnaire de queues et la place libre est immédiatement récupérée au profit d'autres jobs, et donc au détriment de l'utilisateur en court de mise au point.
Un planificateur ne fonctionne pas en mode immédiat mais sur le moyen terme. Tous les besoins sont rassemblés, incluants gros jobs, périodes de mise au point, etc., et agencés au mieux sur un calendrier. On évite les inconvénients mentionnés ci-dessus par un système d'allocations quasi exclusives.
Par contre, l'utilisation optimale de la machine passe par le remplissage optimal du calendrier et des réservations. Et ceci passe par une démarche de chaque utilisateur qui aura une responsabilité morale de la bonne utilisation des ressources qui lui sont réservées, à l'inverse d'une gestion type pbs, plus globale, reposant sur le "premier arrivé premier servi".
Voici donc quelques commentaires et options utiles de rplan pour gérer l'organisation de ses tâches.
Éviter de faire des "trous". Un slot est un peu une mini machine avec un plus faible nombre de tâches en attente que sur un gros cluster. Il est utile de prévoir la liste des calculs à faire dans un futur proche en groupant par nombre de processeurs nécessaires.
Avoir toujours de quoi remplir son slot. Il est important que les allocations correspondent à une liste de travaux à faire et non juste à "occuper le terrain au cas où". On peut sans problème soumettre un peu plus de tâches que la taille théorique du slot ce qui permet de toujours alimenter dans le cas où certaines tâches vont durer moins longtemps que prévu.
Ne jamais laisser un slot vide ! C'est dommage et cela a tendance à irriter d'autres utilisateurs qui voient, par exemple, 32 processeurs inactifs pendant tout un week-end alors qu'eux mêmes ont une pile de jobs en attente.
Il existe plusieurs techniques anti slots vides :
L'enlever, options -r ou -kill dès lors que l'on sait que l'on n'en a plus l'usage. En particulier ne PAS partir en week-end en laissant un slot inutilisé.
Le donner à un autre utilisateur, option -u <user>, c'est une alternative à la destruction.
Utiliser l'option -r, remove when empty, chaque fois que l'on sait que l'on n'en aura plus besoin une fois les tâches en cours terminées. C'est une bonne habitude à prendre et ça peut permettre d'avancer ce qui attend derrière.
Utiliser l'option -x, expansion mode, sur la dernière tâche d'un slot si le calcul s'y prête. Cela permet d'avancer le plus loin possible dans le temps de slot disponible.
À noter que cette manoeuvre n'est pas incompatible avec l'option remove. En principe le mode expansion fait que la dernière tâche va aller jusqu'au bout du temps de slot, sauf arrêt imprévu et anticipé. Auquel cas, le slot disparaitra.
Le lanceur de tâches rwrap
En complément de rplan, un programme annexe, rwrap, est destiné au lancement correct des exécutions.
Architectures multi processeurs
Les machines fortement multi processeurs disposent de fonctionnalités système appelées cpusets, qui permettent de définir des groupes de processeurs par partitions. Les programmes lancés dans un cpuset ainsi que leurs processus enfants ne disposeront que des ressources de ce cpuset, sans interférences possibles avec le reste de la machine.
D'autres outils, a priori, indépendants permettent de placer et fixer des processus en exécution à tels ou tels processeurs physique. L'intérêt est principalement d'augmenter la performance en évitant les migrations de processus entre les différents cpus de la machine, chose que les systèmes Unix pratiquent sans états d'âme.
L'inconvénient est que si deux utilisateurs placent leur(s) processus sur un même processeur par accident (i.e. sans s'être concertés), ce processeur fonctionnera en temps partagé pour les deux processus, même si le reste de la machine est inutilisé. De fait, le placement n'a guère de sens qu'en liaison avec des cpusets non concourants.
Support par les gestionnaires de tâches
Le calculateur du CEMAG dispose de trois gestionnaires de tâches :
Torque, ou OpenPBS. Aucun support de cpusets ou de placement, ce dernier étant à la charge de l'utilisateur via une commande système, dplace.
PBSPro sans support cpusets. Même situation qu'avec Torque.
PBSPro avec support cpusets. Pour chaque tâche lancée, PBSPro va créer dynamiquement un cpuset de la taille convenable (nombre de processeurs demandés) et lancer la tâche dedans. Le placement n'étant pas pris en charge et restant du ressort de l'utilisateur.
Ceci fonctionne très bien pour les tâches scalaires ou multi processus s'exécutant sur un seul noeud de calcul. (Applications OpenMP par exemple). Ceci ne fonctionne pas du tout pour les tâches MPI, lesquelles déploient les différents process de la tâche, sur une ou plusieurs machines du cluster, par un mécanisme (array daemon) qui court circuite les cpusets de PBS.
On dira que ce n'est la faute de personne en particulier, mais simplement la conséquence de deux outils logiciels, PBSPro de Altair et mpirun de SGI, qui ne se connaissent pas.
Le lanceur rwrap
Ce programme a été conçu pour travailler en collaboration avec rplan et, de fait, répondre au problème évoqués ci-dessus. Il intègre un support de cpusets (en collaboration avec rplan), il assure le placement sur les processeurs (l'utilisateur peut oublier la commande dplace), enfin il est compatible avec les tâches MPI.
Comme tout lanceur (ou wrapper) de programme, il doit être invoqué devant le nom effectif du programme à exécuter. Par exemple, pour un programme scalaire ou OpenMP :
rwrap ./progomp.exe
ou, pour un programme MPI :
mpirun rwrap ./progmpi.exe
En utilisation courante, c'est tout ce qu'il y a à faire. Il accepte quelques options utilisateurs, décrites ci-dessous. Lors du traitement des scripts de soumission, effectué par rplan, l'invocation de ce programme sera détectée et rplan introduira d'autres options de lancement, en particulier les informations de cpuset à utiliser.
Options
rwrap assure le démarrage du programme dans le ou les cpusets dédiés. Cette opération est faite en collaboration avec rplan et ne nécessite aucune intervention utilisateur.
rwrap assure aussi le placement éventuel des processus associés à la tâche. À ce titre, il accepte quelques options de placement de la même manière que l'utilitaire dplace.
NB: dplace ne doit plus être utilisé dans les scripts de soumission. Lors de l'analyse des scripts, rplan préviendra par un message d'avertissement. C'est rwrap qui doit être invoqué pour les options de placement. Les options similaires entre ces deux outils ont la même syntaxe.
| -c <n1>-<n2> | Même option que pour dplace. Spécifie un intervalle de processeurs où placer les processus. L'adressage processeurs est relatif au cpuset, i.e. le premier a toujours le numéro 0. Dans les cas courants, programmes MPI purs, cette option n'est guère utile, rwrap reconstruira une spécification de placement par défaut à partir de l'intervalle du cpuset. |
| -s <N> | Même option que pour dplace. Demande d'ignorer les <N> premiers processus, lors du placement. Par défaut, si cette option n'est pas spécifiée, rwrap utilisera -s1 pour les tâches MPI où l'on ignore le processus MPI lanceur. |
| -x <N> | Même option que pour dplace. Demande de placer un processus sur <N>. Utilisé pour des programmes OpenMP où l'on doit, en principe, ignorer les processus intermédiaires créés lors de la duplication des threads. La valeur est dépendante de la librairie OpenMP utilisée, pour notre système c'est -x2 |
| -n <N> | Option propre à rwrap. Demande de ne placer que les <N> premiers processus, sans tenir compte de la taille du cpuset. Par exemple, dans un cpuset de taille 32, rwrap va générer par défaut un placement sur 0-31. En ajoutant une option, par exemple -n8, le placement produit sera 0-7. Utile pour des applications mixtes, MPI et OpenMP, où l'on souhaite ne placer que les processus MPI mais non leurs threads. |
| -z | Option propre à rwrap. On ne fait pas de placement, seul le lancement dans le cpuset est assuré. |
D'autres options de placement particuliers, e.g. sur CPU pairs, ou impairs, sont en cours.
