Foire aux questions (FAQ)

FAQ

    Accès aux services du CISM

En quoi consistent les services ?
Comment devenir un utilisateur ?
Qui contacter ?

    Le système de stockage de masse

Quelle est l'infrastructure disponible ?
Quel est le coût pour l'utilisateur ?

    Utilisation des ressources de calcul intensif

         Quelles sont les machines disponibles ?
         Quel est le coût pour l'utilisateur ?
Comment accéder aux machines du CISM depuis l'extérieur ?
Comment transférer des fichiers entre une machine du CISM et une machine extérieure ?
     Le calcul parallèle
          Quels sont les principes de base ?
          Quelle plate-forme choisir ?
          Y a-t-il des ouvrages de référence disponibles ?

    La soumission des tâches

         Quel est le principe des systèmes "batch" ?
         Comment écrire un script de soumission à PBS ?
         Comment écrire un script de soumission à SGE ?
         Quelles sont les limites imposées par SGE ?
         Comment la priorité d'un job est-elle établie ?
         Comment le mécanisme de réservation de ressources fonctionne-t-il ?
         Quelles sont les commandes SGE les plus intéressantes ?

Accès aux services du CISM

 En quoi consistent les services?

Le CISM offre l'accès à des ordinateurs spécialement conçus et configurés pour le calcul intensif ainsi qu'à un système de stockage de masse (capacité totale de 40 To). En complément, l'équipe de gestion assure le support direct aux utilisateurs (aide au débogage et optimisation de codes, support pour environnement UNIX,...)

 Comment devenir un utilisateur?

L'infrastructure du CISM est accessible à toute personne membre de l'UCL. Il suffit d'en faire la demande à l'équipe de gestion via le responsable d'unité. Lire les dispositions particulières aux utilisateurs des machines de calcul et à ceux du système de stockage de masse.

 Qui contacter?

Une équipe de trois informaticiens assure la gestion quotidienne de l'infrastructure. Elle peut être contactée par E-mail: . Voyez aussi la page de l'équipe.

Le système de stockage de masse
 Quelle est l'infrastructure disponible?
  trois systèmes de stockage sur disques sont disponibles:
  • lemaitre: serveur Sun connecté à une baie de disques SATA d'une capacité de 18 To .
  • storage02: serveur Sun connecté à une baie de disques SATA d'une capacité de 36 To .
  • storage03: serveur Transtec connecté à une baie de disques SATA d'une capacité de 50 To .

L'utilisateur a la possibilité d'organiser des réplications de fichiers entre deux systèmes (qui sont localisés dans des bâtiments différents).

Les échanges entre la machine de l'utilisateur et un des serveurs utilisent en principe le protocole FTP

Vous trouverez ici une description plus détaillée.

 Quel est le coût pour l'utilisateur?
Pour la facturation, on distingue deux classes d'utilisateurs: ceux s'engageant à payer, pour une période de trois ans, un forfait annuel couvrant une capacité convenue à l'avance, et ceux payant chaque année un montant proportionnel à l'espace occupé sur le système (et calculé sur base mensuelle). Le Conseil de Direction du CISM révise annuellement les tarifs en fonction de la demande et du coût des investissements.Lire les détails de la facturation actuelle.
Utilisation des ressources de calcul intensif

 Quelles sont les machines disponibles?

Le parc de machines est essentiellement composé: 

  • d'un serveur HP "Turing" (acquis en 2000, en fin de vie)
  • d'un serveur HP Itanium "Chpit" (acquis en 2003)
  • d'un cluster de machines Compaq ES40/ES45 "Decci" (acquis en 2000-2003, en fin de vie)
  • d'un cluster de machines SUN "lemaitre" (128 bi-processeurs AMD Opteron avec interconnexion Infiniband, aquis en 2005) et de serveurs SMP de 4 à 16 processeurs, de 24 à 128Go de RAM
  • d'un cluster de machine Dell "Green" 816 coeurs : 102 machines huit coeurs, de 16Go ou 32Go de RAM

    Un tableau synoptique des équipements est disponible

 Quel est le coût pour l'utilisateur?

Pour les utilisateurs sporadiques ou pour ceux dont les besoins sont légers, rien: l'utilisation des ressources du Calcul Intensif est gratuite. Lorsque l'utilisation devient substantielle, l'unité utilisatrice est appelée à s'investir dans la gestion de l'outil au sein du Conseil de Direction du CISM. Lire aussi.

 Comment accéder aux machines du CISM depuis l'extérieur?

Les machines de calcul sont accessibles en ssh depuis toutes les machines de la communauté universitaire. Pour un accès depuis l'extérieur de l'UCL, deux solutions sont envisageables:

  • l'utilisation du VPN, service fourni par l'entité SGSI/SRI, à laquelle il faut en faire la demande. De cette manière, votre machine reçoit, pendant la période de connexion sécurisée, une adresse IP "UCL".
  • vous demandez à l'équipe de gestion un mot de passe spécifique pour accéder, en ssh, à la machine hall.cism.ucl.ac.be. A partir de hall, vous pouvez alors vous connecter sur les autres machines du CISM.

Comment transférer des fichiers entre une machine du CISM et une machine extérieure?

Plusieurs solutions s'offrent à vous

  • si vous utilisez le VPN pour accéder aux machines du CISM, vous pouvez utiliser la commande "scp" entre la machine CISM utilisée et la machine cible.
  • si vous passez via la passerelle d'accès hall.cism.ucl.ac.be, vous avez le choix entre:
       o  sur hall, exécuter un "scp machine_CISM_utilisée:monfichier ./trans/" qui copiera le fichier en question sur le répertoire cible ./trans/ (sur hall). Faire suivre alors cette commande par un "scp trans/monfichier ma_machine_destination:" qui enverra le fichier vers la machine que vous souhaitez. Notez que le répertoire ./trans/ est nettoyé toutes les nuits. Il ne vous est pas non plus accessible directement. Vous devez donc connaître le nom du fichier que vous y avez déposé.
       o utiliser un tunnel ssh entre la machine du CISM et votre machine cible, de la manière suivante:
                    + créer un tunnel ssh entre la machine CISM où se trouve votre fichier, et votre machine cible (qui doit être serveur ssh, port 22) en tapant, sur la machine source du CISM: "ssh -l mon_login -L 1234:ma_machine_cible:22 user@hall" où
                          # "1234" est un port arbitraire que vous pouvez choisir (au-dessus de 1024)
                          # "mon_login" est votre login sur la machine cible
                          # "user" est votre login sur hall (identique à votre login au CISM)
                    + à partir d'une autre session sur la machine source CISM, utiliser la commande "sftp -oPort=1234 mon_login@localhost"
                    + à la fin du transfert, terminer la connexion tunnel ssh

 Le Calcul Parallèle

Quels sont les principes de base ?

Une des particularités du CISM est de proposer des environnements spécifiques de calcul parallèle, soit de type SMP (Symetric Multi-Processors), où plusieurs processeurs partagent une mémoire commune, soit de type mémoire distribuée ("cluster" ou grappe) où chaque processeur travaille avec de la mémoire propre, soit de type mixte (grappe de machines SMP).

Deux standards ont émergé en tant qu'environnement de travail:

  • OpenMP: c'est une extension des compilateurs (FORTRAN ou C) qui leur permet, via des directives insérées dans le code source, de distribuer certaines opérations (typiquement des boucles DO) sur plusieurs processus. Cette approche permet de paralléliser assez rapidement un code existant.
  • Message Passing Interface (MPI): il s'agit d'un standard qui permet de gérer de manière explicite la communication entre processus. C'est ici au programmeur de coder les détails des interactions entre les différents processus.

L'équipe de gestion organise régulièrement des séances d'introduction aux deux outils précités. Les copies des dernières présentations OpenMP et MPI sont disponibles en ligne.

Par ailleurs, pour optimiser les performances de calcul, il est primordial qu'un seul processus tourne sur chaque processeur. C'est la raison pour laquelle les utilisateurs ne peuvent lancer leurs tâches en mode interactif, mais doivent les soumettre via un système batch.


Quelle plate-forme choisir?

Alors que le cluster decci (7 noeuds quadri-processeurs alpha) reste intéressant, c'est la grappe lemaître   qui offre plus de  performances de calcul, une technologie d'interconnexion à très faible latence (Infiniband), ainsi que des capacités mémoire intéressantes (32 Go, 64 Go et 128Go de RAM). la grappe Green offre de meilleures performances, un nombre elevé de processeurs (816 coeurs répartis en 102 machines octo-cpu) mais l'interconnect gigabit ethernet n'est pas aussi performante que l'infiniband (d'où la mise en place de l'environnement snode ou snode8)

Y a-t-il des ouvrages de référence disponibles?

Un certain nombre de livres spécifiques au calcul parallèle et à l'optimisation de code sont disponibles pour consultation au PCPM (Bâtiment Boltzmann; Place Croix du Sud, 1). Il est possible de les emprunter pour de courtes périodes, et moyennant dépôt d'une caution de 25 EUR.

MPI, The Complete Reference
Marc Snir et al.; MIT Press

High Performance Computing
Kevin Dowd, Charles Severance; O'Reilly

Performance Optimization of Numerically Intensive Codes
Stefan Goedecker, Adolfy Hoisie; Siam

Fortran 90 for Engineers and Scientists
Larry R. Nyhoff, Sanford C. Leestma; Prentice Hall

Fortran 90 for Scientists and Engineers
Stephen Chapman; Mc Graw Hill

Using MPI
William Gropp, Ewing Lusk, Anthony Skjellum; MIT Press

Parallel Programming
Barry Wilkinson, Micahel Allen; Prentice Hall

Parallel Programming in OpenMP
Rohit Chandra et al.; Morgan Kaufmann Publishers

LAPACK User's Guide
E. Anderson et al.; Siam

Introduction to Parallel Computing
Ananth Grama et al.; Addison Wesley

La soumission des tâches

 Quel est le principe des systèmes "batch"

L'avènement de Windows sur les ordinateurs personnels, et les GUI (interfaces graphiques) en général, permettent aux utilisateurs de lancer plusieurs tâches simultanées. La convivialité de cette approche (un système d'exploitation multi-tâches) est néanmoins synonyme de surplus de charge de travail pour le processeur. En effet, pour chaque passage d'une tâche à l'autre, un grand nombre d'opérations d'écriture et de lecture de registres de mémoire sont nécessaires. Dans les environnements où l'on désire optimiser la vitesse de calcul, on veille donc à garantir que chaque processeur soit affecté à une et une seule tâche. C'est l'objet du système de batch: plutôt que de soumettre leurs tâches en mode interactif, les utilisateurs passent par un logiciel qui lance l'exécution des tâches de manière séquentielle, sur base des demandes reçues des utilisateurs.

En pratique donc, plutôt que de lancer un job en entrant une commande du style

/home>./mon_job

l'utilisateur soumettra une requête au système batch comme suit:

/home> qsub mon_script_de soumission

où le script de soumission détaille les besoins du programme mon_job tels que:

Le système de batch lancera alors la tâche dès que les ressources requises par l'utilisateur seront disponibles. Il veillera aussi à offrir à chaque utilisateur, en moyenne, un accès équitable aux ressources.

Deux systèmes de gestion des tâches sont utilisés:

Dérivés du Network Queueing System (NQS puis NQS+), SGE et PBS acceptent également les commandes "qsub", "qdel" et "qstat" pour respectivement soumettre un job, supprimer un job et avoir des informations sur la situation courante des queues de travaux. Par contre, la syntaxe du script de soumission est spécifique à chaque environnement. Nous recommandons vivement la lecture, sur la plate-forme utilisée, du manuel en ligne (man pages) relatif à ces commandes.

Comment écrire un script de soumission à PBS ?

Un script PBS a pour objectif de:

Toutes les informations destinées à PBS sont incluses dans des lignes commençant par #PBS. Voici un exemple de script:

#! /bin/csh
# on garde l'environnement
#PBS -V
# un E-mail au début (begin) et à la fin (end) :
#PBS -m be -M monemail@unité.ucl.ac.be
if !( -d /scratch/$USER) then
mkdir /scratch/$USER
endif
# on est certain que PBS_JOBID est unique et n'existe pas encore
set WD = /scratch/$USER/$PBS_JOBID
mkdir $WD
cd $WD
cp $HOME/mes_donnees .
# ou le rcp par exemple:
# rcp dixi:/scratch/mon_run_precedant/data1.dat .
# dans un noeud disposant de 4 processeurs
#PBS -l nodes=1:ppn=4 -lncpus=4
/bin/time $HOME/somewhere/executable < input.dat > ouput.dat
# post-traitement ( envoi vers le stockage, ou copie dans le "home",...)
# idéalement libérer le répertoire $WD si tout s'est bien passé:
# /bin/rm -r $WD

Pour le détail des arguments et options de PBS, on se référera à "man qsub". Par ailleurs, quelques attributs spécifiques à chaque plate-forme ont été définis:

Important: les utilisateurs sont invités à évaluer correctement les ressources nécessaires (nombre de CPUs ou RAM) pour une exécution correcte de leur programme, de manière à ne pas en demander (et monopoliser) plus que leur besoin réel.

Comment écrire un script de soumission SGE?

La syntaxe permettant d 'inclure des paramètres propres à SGE dans votre script suit la forme suivante:

#$ Paramètre_SGE

Toutes les informations destinées à SGE sont incluses dans des lignes commençant par #$ . Les paramètres obligatoires sont marqués de (*)

a) les paramètres communs aux grappes "lemaitre" et "green":

-l h_rt=x    (*) limite du temps d'exécution en secondes ou en heures:minutes:secondes, le maximum est de 10 jours,     soit 864000 secondes ou 240:00:00

-l h_vmem=x    taille de la mémoire; lorsque la demande dépasse 1.7 Go pour un noeud bi-processeurs de "lemaitre", SGE attribue un noeud complet par processus, e.g. "0.6G" (pour GigaOctets). Il est impératif de supprimer tous vos fichiers de cet espace à la fin de chaque job (script).

-R y        active la réservation de processeurs, est recommandé lorsque votre job en a besoin de beaucoup

b) les paramètres spécifiques à "lemaitre":

Nombre maximum de slots par utilisateur: 64 CPU

-l h_rt=x    (*) limite du temps d'exécution en secondes ou en heures:minutes:secondes, le maximum est de 10 jours,     soit 864000 secondes ou 240:00:00

-l h_vmem=x    taille de la mémoire; lorsque la demande dépasse 1.7 Go pour un noeud bi-processeurs de "lemaitre", SGE attribue un noeud complet par processus, e.g. "0.6G" (pour GigaOctets). Il est impératif de supprimer tous vos fichiers de cet espace à la fin de chaque job (script).

-R y        active la réservation de processeurs, est recommandé lorsque votre job en a besoin de beaucoup

-l ib=true     pour utiliser la liaison "Infiniband" entre les noeuds [parfois hors service entre 2 ou plusieurs noeuds]

-l p= x    (*) choix des noeuds selon le type de processeur ( "propertie" )

         2     bi-processeurs: lm11 - lm104, lm137, lm138

         8     lm6, lm7, lm8 (4 ou 8 CPU, 64 ou 32 Go de mémoire RAM)

        16     lm140 (16 CPU, 64 Go de mémoire RAM)

        128     lm143 - lm145 (8 CPU, 128 Go de mémoire RAM)

        5520    lm241 - lm252 (12 nodes 8 CPU, 24 Go de mémoire RAM)

-l scratch= x     pour s'assurer d'un espace de travail "scratch" d'une taille donnée dès le démarrage du job, e.g. "5.0G" (pour GigaOctets). Il est important de veiller à supprimer tous vos fichiers "scratch" à la fin du job.

-pe PEmode nombre_CPU définit le mode de calcul parallèle et le nombre de processeurs requis:

    mpich     dans cet environnement, SGE s'efforce d'occuper tous les processeurs de chaque machine en service

    smp      est l'environnement "shared memory", i.e. tous les processeurs d'une même machine sont attribués à un seul job; le nombre_CPU est alors limité à 32;

    snode  (same node)   dans cet environnement, SGE attribue les 2 processeurs d'un (ou de plusieurs) noeud(s) bi-processeurs à votre travail, ce qui évite des interférences avec les autres travaux;

    lp         (long parallel) cet environnement est similaire à snode mais les processeurs sont attribués par groupes de 8, 16, 32 ou 64; cela implique l'utilisation de la queue "lpar.q"

 -l abaqus=5     demande 5 jetons d'utilisateurs(licences) du logiciel "abaqus"; la commande "qla [-f]" fournit des informations à ce sujet;

-l fluent= x     demande x jetons d'utilisateurs(licences) du logiciel "fluent"; la commande "qlf [-f]" fournit des informations à ce sujet;

-l fluentpar= x     idem pour le logiciel "fluentpar"

-l matlab=true     pour utiliser le logiciel "matlab"; celui-ci n'est installé que sur lm7 et lm8 !

-q queue     spécifie la file d'attente du travail

Queues Noeuds
RAM
PE
Temps Max (-l h_rt)
all.q
lm11 à lm104
4 GB
mpich,smp,snode
10 jours
all.q
lm6 et lm140
64 GB
mpich,smp,snode
10 jours
all.q
lm7 et lm8
32 GB
mpich,smp,snode
10 jours
all.q
lm143 à lm145
128 GB
mpich,smp,snode
10 jours
all.q
lm241 à lm252
24 GB
mpich,smp,snode
10 jours
fast.q
lm137 et lm138
4 GB
mpich,smp
2 heures
lpar.q
lm105 à lm136
4 GB
lp
10 jours


c) les paramètres spécifiques à "green":

Nombre maximum de slots par utilisateur: 204 CPU

-l h_rt=x    (*) limite du temps d'exécution en secondes ou en heures:minutes:secondes, le maximum est de 5 jours,     soit 432000 secondes ou 120:00:00

-l h_vmem=x    taille de la mémoire, e.g. "0.6G" (pour GigaOctets). Il est impératif de supprimer tous vos fichiers de cet espace à la fin de chaque job (script).

-R y        active la réservation de processeurs, est recommandé lorsque votre job en a besoin de beaucoup

-l mf=x     (*)   mémoire libre demandée, e.g. 8G

-l hm=x    (*)

    true    pour exécution dans des noeuds à mémoire "haute" (32 Go)

    false   pour exécution dans des noeuds à mémoire "basse" (16 Go)

-pe PEmode nombre_CPU définit le mode de calcul parallèle et le nombre de processeurs requis:

    mpich     dans cet environnement, SGE s'efforce d'occuper tous les processeurs de chaque machine en service

    openmpi   dans cet environnement, SGE s'efforce d'occuper tous les processeurs de chaque machine en service

    snode     dans cet environnement, SGE attribue tous les processeurs (cores) d'un (ou de plusieurs) noeud(s) à votre travail, ce qui évite des interférences avec les autres travaux;

    snode8    comme dans l'environnement snode, sauf que l'attribution des processeurs se fait par groupes de 8, 16, 32 ou 64; cela implique l'utilisation de la queue "snode8.q"

             -l nb=x    (*)

                 true  utilisation de New Branch

                 false   si on ne veut pas utiliser les machines de New Branch

          -q
queue     spécifie la file d'attente du travail


Queues

Noeuds
RAM
PE
Temps Max (-l h_rt)
all.q
node013 à node048
32 GB
mpich,openmpi,snode,snode8
5 jours
all.q
node049 à node079
16 GB
mpich,openmpi,snode,snode8
5 jours
all.q
node097 à node098
32 GB
mpich,openmpi,snode,snode8
5 jours
fast.q
node080 à node095
16 GB
mpich,openmpi,snode,snode8
24 heures
snode8.q
node001 à node008
32 GB
snode8
5 jours
long.q
node009 à node012
32 GB
mpich,openmpi,snode,snode8
15 jours
long.q
node099 à node102
32 GB
mpich,openmpi,snode,snode8
15 jours
nb.q
node 105 à node120
16 GB
snode8
5 jours


 

d) voici un exemple type de script SGE (les lignes commençant par # sont des commentaires, sauf la première, commençant par #! qui définit l'interpréteur "shell", ainsi que celles commençant par #$, destinées à SGE):

# SGE example1 on Lemaitre Cluster
#!/bin/sh
#
# SGE: the job name
#$ -N My_MPI_Job
#
# SGE: pe=parallel environnemnt request
# and the number of proc. needed
# SGE: here mpich with 6 proc.
# SGE: smp or snode also exist
#$ -pe mpich 6
#
# SGE: mandatory!! the requested run-time, expressed as
#$ -l h_rt=xxxx
# (xxxx sec or hh:mm:ss (max 10 days=240:0:0)
# SGE will kill your job after the requested period.
#
# SGE: definition of the machine type (p=propertie)
# -l p=2 for biproc node lm11 to lm138
# -l p=4 for cauchy and cauchy2 (pamo only)
# -l p=8 for SMP lm6 (8cpu,64GB),...
#            lm7 (8cpu,32GB,matlab)
#            lm8 (4cpu,32GB,inma,matlab)


# -l p=16 for SMP lm140 (16CPU,64GB)
# -l p=128 for lm143-lm144-lm145 3x(8cpu,128GB)
# -l p=5520 for lm241 to lm252 12x(8cpu,24GB)
#

#  set p=5520 for 12 new HP proliant with Xeon L5520@2.27GHz
# with infiniband 40Gb/s interconnect
#(see end of example for specific openmpi job)
# lm241 to lm252: 96 core(32 astr + 64 all)
# att! lm241 to lm244 astr only (32 core)
#      lm245 to lm252 all cism  (64 core)

#$ -l p=2
#
# SGE: your Email here, for job notification
#$ -M my@mail.ucl.ac.be
# SGE: when do you want to be notified (b for begin, e for end, s for error)?
#$ -m bes
#
# SGE: ouput in the current working dir
#$ -cwd    
#
echo "Got $NSLOTS slots."
echo "Temp dir is $TMPDIR"
echo "Node file is:"
cat $TMPDIR/machines
/usr/local/mpich/bin/mpirun -nolocal -np $NSLOTS -machinefile
# end of job

###############################################################################
# Here below: 5520 specific openmpi  with infiniband, on lemaitre cluster
#$ -l p=5520
#$ -N myopenmpijob
#$ -pe mpich 16
# memory request
#$ -l mf=1G
# time limit in hh:mm:ss (max 10 days=240:0:0)
#$ -l h_rt=24:00:00

. /etc/profile.d/modules.sh
module purge
module add shared intel/cce intel/fce openmpi/intel

# with openmpi 1.3.3 DON'T set the -machinefile flag!
echo start at
date
mpirun -np $NSLOTS cpi.openib
echo end at
date
# ---- end myopenmpijob


##########################################################################################
# SGE example on NewBranch of GREEN Cluster
#!/bin/sh
#
# parallel environment and NSLOTS
#$ -pe openmpi 4
# my job name
#$ -N JOB_ON_NEW_BRANCH
#memory request
#$ -l mf=4G
# requested time. Max is 5 days (120:00:00
#$ -l h_rt=2:00:00
#
# Use New Branch
#$ -l nb=true
# do not set -cwd with new branch! (no home directory)!
# use -wd instead:
#$ -wd /scratch
#
#$ -M My_real@email
# a mail for b/e/s begin, end, stop
#$ -m bes
# ---------------------------
. /etc/profile.d/modules.sh
module purge
module add shared intel/cce intel/fce openmpi/intel gotoblas/penryn

echo "Got $NSLOTS slots."
echo "Temp dir is $TMPDIR"
echo "Node file is:"
cat $TMPDIR/machines

WDIR=/scratch/$USER/$JOB_NAME-$JOB_ID
MYEXEC=$HOME/examples/myexec
MYLOCALEXEC=$WDIR/myexec

# Create Working Directory on each allocated node
# and copy data & prog from homedir to /scratch of each node

for n in $(cat $TMPDIR/machines|uniq); do
    rsh $n mkdir -p $WDIR
    rcp storage01:$MYEXEC $n:$WDIR
done

cd $WDIR
echo -n "job starts at "
date

mpirun -np $NSLOTS $MYLOCALEXEC

echo -n "job ends at "
date
# end of job

# copy data back to homedir
for n in $(cat $TMPDIR/machines|uniq); do
    rsh storage01 mkdir -p "$HOME/$JOB_NAME-$JOB_ID/$n"
    rsh $n "/bin/rm -f $MYLOCALEXEC"
    f=`echo "$n:$WDIR storage01:$HOME/$JOB_NAME-$JOB_ID/$n"`
    rcp -rp $f
    rsh $n "/bin/rm -rf $WDIR"
done

# copy .o .e .pe .po to homedir
f=`ls /scratch/*$JOB_ID`
f=`echo $f storage01:$HOME/$JOB_NAME-$JOB_ID`
rcp  -p $f

Quelles sont les limites imposées par SGE ?

Le système batch SGE est configuré pour permettre:

 - l'utilisation simultanée de 64 processeurs par utilisateur, dont un maximum de 16 sur les machines SMP (lmexec-6/7/8/140)
- la soumission de jobs de maximum 10 jours (dans la queue normale) ou deux heures (dans la queue rapide, comportant 4 processeurs)

Comment la priorité d'un job est-elle établie?

Actuellement, le système est configuré pour que tous les utilisateurs de l'UCL reçoivent un accès équivalent au cours du temps: SGE tient compte en permanence de l'utilisation des ressources du système par chaque utilisateur. Avec un temps de demi-vie de 14 jours (l'importance de ressources utilisées il y à 14 jours est la moitié de celle des ressources utilisées aujourd'hui), SGE accumule les ressources utilisées dans le passé: le nombre de processeurs intervient pour 85% dans ce calcul, la mémoire pour 15%. Sur cette base, SGE alloue une priorité normalisée à chaque job (1 = priorité maximum, 0 priorité nulle). Sun ne publie pas l'algorithme de calcul. Cette valeur est reprise dans la deuxième colonne du tableau produit par la commande qstat (cfr. infra).

Comment le mécanisme de réservation de ressources fonctionne-t-il ?

Ce mécanisme permet de réserver des ressources avant le démarrage d'un job. Dans le cas de travaux parallèles, il s'agit de "slots" d'exécution (i.e. des CPUs). Soit un job demandant un nombre important de CPUs pour son exécution (par exemple 16 CPUs). Sans le mécanisme de réservation, il faudrait trouver un moment où 16 CPUs soient disponibles pour que le job démarre. Dans un contexte d'utilisation intensive d'un cluster, cette condition a une faible probabilité de se réaliser. Si maintenant ce même job est soumis en utilisant l'option "-R y", qui active la réservation de ressources, le scénario sera différent. Dès que le job soumis entre dans une file d'attente, le gestionnaire des tâches SGE va, à chaque cycle, procéder à la réservation de CPUs répartis sur l'ensemble des machines du cluster. Pour chaque CPU libre sur le cluster, le mécanisme procède de la manière suivante:

    1. s'il y a dans la même file d'attente un job en attente de ressources, dont la priorité est plus haute que celle du job qui a demandé la réservation de ressources, le CPU est octroyé au job ayant la plus haute priorité;
    2. s'il y a un job de plus basse priorité, mais qui annonce un temps d'exécution inférieur au temps estimé par le système pour que l'ensemble des CPUs réservés pour le premier soient réunis, le CPU est octroyé au job ayant la plus basse priorité. Dès que son exécution est terminée, ce CPU est versé à l'ensemble des CPUs réservés;
    3. sinon, ce CPU est immédiatement versé à l'ensemble des CPUs réservés;
    4. le job démarre lorsque l'entièreté des ressources qu'il a demandées sont disponibles dans la réserve. Etant donné que nous ne pouvons prévoir à l'avance les spécificités des jobs qui se trouveront simultanément dans la file d'attente, il est impossible de prédire quand un job utilisant ce mécanisme commencera son exécution.

Comme vous l'aurez remarqué, l'algorithme de réservation se base sur le temps d'exécution estimé par les utilisateurs. Il est donc important d'ajuster cette valeur le plus correctement possible.

Quelles sont les commandes SGE les plus intéressantes ?

La commande 'qstat' permet d'avoir des informations sur les jobs en attente et en cours d'exécution. Depuis la version SGE 6.1, qstat ne donne, par défaut, que cette information pour les jobs de l'utilisateur qui lance la commande. Pour obtenir l'ensemble des jobs, utiliser la commande:

qstat -u "*"

Si vous créez, dans votre répertoire racine (home), un fichier .sge_qstat qui contient la ligne suivante:

-u *

le comportement par défaut de qstat sera d'afficher les jobs de tous les utilisateurs. La liste fournie par cette commande permet de voir la priorité allouée par SGE à chaque job, reprise en deuxième colonne (1 = priorité maximum; 0 = priorité minimum)

La commande 'qstat -g c' fournit un tableau présentant les processeurs disponibles et ceux utilisés.

La commande 'qstat -j n°_de_job' fournit le détail des infos disponibles pour un job, y compris la raison éventuelle pour laquelle ce job ne démarre pas.

La commande 'qquota -u "*"' permet d'afficher le nombre de processeurs utilisés par chaque utilisateur.

La commande 'qload' donne l'état d'occupation globale des processeurs:

lm6 (-l p=8): 7/8 7.02
lm7 (-l p=8): 5/8 5.01
lm8 (-l p=8): 3/3 4.18
lm140 (-l p=16): 10/16 9.99
lm143 (-l p=128): 6/8 6.00
lm144 (-l p=128): 6/8 6.00
lm145 (-l p=128): 4/8 4.01
5520 (-l p=5520): 96/96 (100 %) a: 32/32 (100 %) r: 64/64 (100 %)
lm (-l p=2): 178/256 (69 %) lpar.q: 16/64 (25 %) fast.q: 0/4 (0 %) all.q: 162/188 (86 %)

green : 733/792 (92 %) 16GB(not fast): 315/360 (87 %) 16GB(fast): 7/8 (87 %) 32GB(not snode8): 276/296 (93 %) 32GB(snode8): 128/128 (100 %)

La commande 'Qstat' donne, pour chaque job, le détail des noeuds sur lequel il tourne (ainsi que sa consommation globale de temps cpu et mémoire).

| 16/09/2010 |

| éditeur responsable : Luc Sindic | secrétariat : , | vie privée | règlements |