Environnement

Connexion à la machine

Elle s’effectue en ssh sur : occigen.cines.fr

ssh <mon_login>@occigen.cines.fr

Le système d’exploitation est de type linux basé sur une BullX SCS6 (Redhat 7.3).
Le cluster comprend plusieurs nœuds de connexion pour les utilisateurs. Lorsque la connexion est établie, l’utilisateur se trouve sur un de ces nœuds. L’affectation des connexions se fait en fonction de la disponibilité des nœuds de login. Il peut arriver que deux connexions simultanées aboutissent sur deux nœuds de login différents.

Bibliothèques communes

Les bibliothèques disponibles peuvent être visualisées ou chargées via les commandes :

  • module avail (pour lister ce qui est disponible)
  • module load <nom du module> (pour charger une librairie ou un logiciel dans votre environnement).
  • module list (pour voir ce que vous avez déjà chargé).
  • module purge (pour retirer un environnement déjà chargé).
  • module show (pour voir le contenu du module)

 

Dans le script SLURM pour donner des indications sur les ressources il est possible d’utiliser les directives suivantes :

  • pour indiquer le nombre de nœuds physique de la machine
    #SBATCH --nodes=W
  • pour indiquer le nombre de tâches MPI qui vont tourner dans chaque nœud demandés (24 cœurs physiques + 24 cœurs hyper threadés)
    #SBATCH --ntasks=X
  • pour indiquer pour les codes OpenMP combien de threads seront affectés par cœurs de la machine
    #SBATCH --threads-per-core=Y
  • pour indiquer la quantité mémoire que l’on désire dans un noeud (ne peut pas dépasser la mémoire totale du nœud, 64 Go ou 128 Go)
    #SBATCH --mem=Z
  • enfin cette directive est un indicateur qui précise que vous ne voulez pas partager le nœud sur lequel va tourner votre job avec un autre job
    #SBATCH --exclusive

Dans un nœud partagé, chaque job peut consommer tout ou partie de la mémoire du nœud.

Dans le schéma qui suit, on peut voir que les deux jobs réclament la partie mémoire correspondante au nombre de cœurs demandés.

shared_node1

Ou alors, un job peut demander à consommer beaucoup plus de mémoire.

shared_node2

Dans ce second cas, le gestionnaire de travaux ne placera pas de nouveau job dans ce nœud, tant que la mémoire ne sera pas libéré. Pour ce cas d’exemple, le job J1 se verra facturé 1 cœur, alors que le job J2 se verra facturé 5 cœurs (maximum entre le nombre de cœur demandés (–ntasks=1) et sa taille mémoire divisé par 5). Sur et exemple simplifié, le maximum est 5, il sera donc facturé 5 cœurs..

Voici quelques exemples d’utilisation de ces paramètres
Exemple1:

 #SBATCH --nodes=1 # Un seul nœud
 #SBATCH --ntasks=48 # Autant de tâches que souhaité
 #SBATCH --threads-per-core=2 # Nombre de tâches par cœur physique : soit un sous multiple du nombre de tâches --> on réserve ici 24 cœurs physiques

Si vous ne réservez pas la totalité des ressources cœurs et/ou mémoire, un autre job pourra démarrer sur le nœud en utilisant les ressources restantes.

Il est possible d’imposer le mode « nœud dédié » en utilisant la directive :

 #SBATCH --exclusive

Si aucune demande mémoire n’est précisée par l’utilisateur dans le script de soumission, le job qui tourne sur un nœud partagé se voit affecter une limite mémoire de 1 Go par tâche.
La valeur par défaut est volontairement faible pour inciter les utilisateurs à définir leurs besoins. Voici la directive à utiliser pour exprimer son besoin mémoire :

 #SBATCH --mem=4000 # 4 Go de mémoire garantie par tâche

Erreurs fréquentes :

Lorsqu’un job dépasse sa demande mémoire le processus qui en est responsable est tué par SLURM et le job arrêté. Les autres jobs actifs sur ce nœud ne seront pas être impactés. Si un job provoque un « débordement mémoire » celui-ci est traité au niveau du noyau Linux et, ni le nœud, ni les autres jobs ne devraient être impactés.
Un message d’erreur apparaît alors dans le fichier de sortie :

/SLURM/job919521/slurm_script: line 33: 30391 Killed /home/user/TEST/mem
slurmstepd: Exceeded step memory limit at some point.

Les jobs partagés seront aussi pris en compte dans le processus de blocage en cas de sur-occupation des espaces de stockage /home et /scratch. Les jobs partagés se verront affectés dans des partitions dont le nom sera suffixé par s. Exemple : BLOCKED_home_s pour un job partagé bloqué pour dépassement d’un quota sur /home.

Pour constater qu’un job est démarré en mode partagé il suffit de regarder la partition dans laquelle il est affecté :

login@occigen54:~/TEST$ squeue -u login
 JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
 919914 shared TEST_SHA login R 0:04 1 occigen3100

On voit que le job 919914 tourne dans la partition shared.

Pour connaître l’état des nœuds partagés lancer la commande : sinfo -p shared -o « %.15n %.8T %.8m %.8O %.8z %.14C »

 gil@occigen57:~/TEST$ sinfo -p shared -o "%.15n %.8T %.8m %.8O %.8z %.14C"
 HOSTNAMES STATE MEMORY CPU_LOAD S:C:T CPUS(A/I/O/T)
 occigen3100 mixed 128000 0.00 2:12:2 24/24/0/48
 occigen3101 idle 128000 0.00 2:12:2 0/48/0/48
 occigen3102 idle 128000 0.00 2:12:2 0/48/0/48
 occigen3103 idle 128000 0.01 2:12:2 0/48/0/48
 occigen3104 idle 128000 0.01 2:12:2 0/48/0/48
 occigen3105 idle 128000 0.00 2:12:2 0/48/0/48
 gil@occigen57:~/TEST$

On voit qu’il y a (au moment de la commande) six nœuds dans la partition « shared » (occigen3100 à 3105).

Le nœud occigen3100 en l’état « mixed » contient déjà un ou plusieurs jobs.

Le nœud était occupé sur la moitié de ses cœurs (24/24/0/48). 24 cœurs alloués, 24 cœurs idle, 0 en l’état « autre », et 48 cœurs maximums par nœuds.

Dernière modification le : 26 janvier 2017