Utiliser efficacement la ressource de calcul

Cette page s'adresse aux utilisateurs qui ont des notions de base sur l'utilisation du Cluster Summit2 (voir ArchitectureSummit2 et IntroSlurm). Elle apporte des éléments supplémentaires pour l'utilisation efficace de la ressource de calcul notamment en terme d'entrées/sorties (fichiers) sachant que les éléments matériels les plus lents du cluster sont les disques durs et les accès réseau.

1. Différentes zones d'espace disques

Le cluster propose à l'utilisateur <USER> plusieurs zones disques accessibles en lecture/écriture :

• le répertoire $HOME visible de la frontale summit2 et des nœuds.

• l'espace de stockage /<zone>/<USER> visible de la frontale et des nœuds (<zone> = gsa, iasi, radar, raid7, swio, moby, o3p, sirocco, mesonh, edi, nhoms).

• l'espace temporaire d'un nœud /workdir/<USER>.

Suivant la machine où l'on se trouve (frontale ou nœud), ces zones sont associées à un disque dur local ou à un espace disque monté par réseau (NFS). Le tableau ci-dessous récapitule le type d'accès disque et les débits théoriques associés :

La frontale summit2 est connectée au réseau du cluster avec une carte Ethernet 1Gb/s : elle partage donc son disque local avec tous les nœuds du cluster sous un débit théorique de 100Mo/s. Les serveurs de fichiers sont connecté au réseau du cluster avec une carte Ethernet 10Gb/s (1Go/s)

2. Où se placer pour compiler ses codes ?

Cette question regroupe en réalité 2 questions :

• dans quelle zone disque faut-il placer les sources à compiler ?
• sur quelle machine peut-on lancer la compilation des sources ?

La compilation d'un code est une opération coûteuse aussi bien en ressource CPU (si les options d'optimisations sont activées -O2, -O3...) mais aussi en accès disques (lecture des attributs des fichiers sources, lecture des sources et écriture des fichiers objets). Elle est d'autant plus coûteuse que le nombre de fichiers sources est grand. Sachant que les espaces disques visibles depuis le cluster sont divers et offrent des performances variées (voir section précédente), nous avons récapitulé dans cette table quelques conseils de bons sens :

Qui dit mauvaise performance pour l'utilisateur, dit saturation des serveurs pour le système et mise en danger du système. Sachez que même si vous modifiez un seul source de votre application avant de recompiler avec l'outil Make, ce dernier passe en revue la date de tous les fichiers sources pour détecter celui qui a été modifié. Une telle opération qui peut paraître anodine lorsqu'on travaille dans un répertoire situé sur le disque dur local, sollicite énormément le serveur de fichier NFS lorsqu'on travaille dans le système de fichier réseau (comme /<zone>/<USER>). En effet, même s'il y a peu d'opérations de lecture/écriture de données proprement dites, le nombre de requête sur les attributs de fichiers (date de dernière modification) par la commande Make peut s'avérer très important et augmente significativement avec la taille de votre projet.

3. Puis-je utiliser le répertoire /tmp comme espace de stockage ?

Que cela soit sur les nœuds, sur la frontale Summit2 (ou sur votre poste de travail), la réponse est : NON ! En effet, cet espace présent sur tous les systèmes Unix, bien qu'accessible à tous en lecture/écriture, est réservé au système et sert à stocker les fichiers temporaires de la majorité des applications Unix que vous exécutez. Si vous saturez cet espace qui est de taille limitée, le système peut devenir instable ou cesser de fonctionner. Vous avez à votre disposition 3 espaces de stockage différents sur le cluster ($HOME, /<zone>, /workdir) : utilisez-les et oubliez le /tmp.

4. Peut-on lancer un xterm sur un nœud ?

Oui, il suffit simplement d'utiliser la commande srun, comme par exemple :

summit2:~> srun -p any -n 1 xterm

La fenêtre Xterm qui s'affiche sur votre écran comporte alors le numéro du nœud. Etant donné que vous êtes sur le nœud, le répertoire /workdir/<USER> est accessible dans cette fenêtre : la commande "cd /workdir/<USER>" est valide.

---

Pour lancer un xterm sur un nœud particulier, spécifier le numéro du nœud avec l'option -w, par exemple sur le nœud n201:

summit2:~> srun -p any -n 1 -w n201 xterm

---

La commande suivante ouvre 4 fenêtres xterm, une sur chaque nœud de l'allocation :

summit2:~> srun -p any -N 4 xterm

Le résultat est différent de la commande ci-dessous qui ouvre également 4 fenêtres xterm mais ces 4 fenêtres peuvent provenir du même nœud car on spécifie l'option -n (permettant d'allouer 4 cpus) :

summit2:~> srun -p any -n 4 xterm

5. Peut-on lancer un xterm sur un nœud déjà occupé par un job ?

Oui, si le job vous appartient ! Il suffit de rajouter l'option --jobid=<JOBID> à la commande srun décrite précedemment.

Dans l'exemple ci-dessous, deux fenêtres xterm sont lancés, une sur chaque nœud du job 26082 :

summit2:~> squeue -u gazdi
  JOBID    PARTITION     NAME     USER  ST       TIME  NODES  CPUS  NODELIST(REASON)
  26082          any     bash    gazdi   R       0:38      2    16  n[17-18]

summit2:~> srun -N 2 --jobid=26082 xterm

Cette opération est utile notamment pour vérifier le bon fonctionnement d'un job : si vous avez redirigé les sorties du job dans le répertoire local /workdir/<USER> des nœuds, c'est le seul moyen d'inspecter l'état de ces fichiers; si vous voulez exécuter la commande top...

---

CatégorieBidon

Remplacer CatégorieBidon par une catégorie appropriée parmi