Questions fréquentes

Mon job reste en queue. Pourquoi ne démarre-t’il pas ?

Causes probables

Il peut y avoir plusieurs raisons à cela, et les plus fréquentes seraient :

  • la machine est très chargée et vous avez déjà beaucoup calculé, alors vous devez attendre un peu plus qu’un autre utilisateur dont la priorié est plus grande, du fait qu’il a déjà utilisé moins de ressources que vous. De ce fait, le système se rééqulibre de lui-même

  • vous avez déjà des tâches en train de s’exécuter et votre nouvelle demande de ressource excède votre quota de ressources que vous pouvez utiliser simultanément. Ce quota est défini afin de répartir les ressources entre chaque utilisateur. Il dépend de votre projet

  • vous travaillez avec un grille de tâche et vous avez pour l’intant atteint la limite des tâches qui peuvent s’exécuter simultanément dans cette grille

  • vous avez mal configuré votre script de soumission, et votre job restera en queue tant que vous ne l’aurez pas corrigé ou supprimé

Solutions possibles

Vérifiez le statut et la raison pour laquelle il est (res. ils sont, si vous en avez plusieurs) en attente, en faisant :

squeue --jobs JOBID1,JOBID2,JOBID3,...

Dans l’exemple ci-dessous, les 2 premiers jobs tournent avec un statut running (ST = R) alors que les deux suivants sont en attente avec un statut pending (ST = PD). La raison pour le job 629777 est l’absence de ressources disponibles alors que le suivant est en attente car le nombre limite de tâches qui peuvent être réalisées simultanément dans sa grille de tâches est atteinte. Exemple :

squeue --jobs 629779,629777,625798
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
         625798_24   cascade   M130T2   cbogey  R   14:41:23      1 cascade-f32-07
          629779_2   cascade   M060T2   cbogey  R   10:17:17      1 cascade-f32-02
   629777_[3-16%1] skylake,c   M110T2   cbogey PD       0:00      1 (Resources)
   629779_[3-22%1] skylake,c   M060T2   cbogey PD       0:00      1 (JobArrayTaskLimit)

Dans l’exemple ci-dessous, l’utilisateur a des tâches qui s’exéctuent, et les suivantes doivent attendre car l’utilisateur a atteint la limite des ressources qu’il peut exploiter simultanément (REASON = Resources) et que les tâches suivantes ne sont pas prioritaires par rapport à d’autres jobs en attente (REASON = Priority)

squeue -u agodard
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
            630109   skylake ESTC_EST  agodard PD       0:00      2 (Resources)
            630121   skylake ESTC_EST  agodard PD       0:00      2 (Priority)
            630122   skylake ESTC_EST  agodard PD       0:00      2 (Priority)
            630104   skylake ESTC_EST  agodard  R    1:59:48      2 skylake-f32-01,skylake-t32-05
            630037   skylake Valid_HC  agodard  R   10:23:49      2 skylake-f32-05,skylake-t32-06

La priorité d’un job par rapport aux autres en attente peut être obtenue via la commande

sprio

On voit ici que les jobs en 630121 et 630122 sont en avant-derniers dans la liste des jobs prioritaires. La priorité est définie par un équilibre entre les différents utilisateurs, qui prend en compte notamment l’ancienneté du job dans la file d’attente (AGE) et l’intensité de l’exploitation des ressources (FAIRSHARE), c’est-à-dire qu’à temps d’attente identique, un utilisateur qui aura peu calculé sera plus proritaire qu’un utilisateur qui aura déjà beaucoup exploité les ressources de calcul. Le système se rééquilibre normalement de lui-même.

 JOBID PARTITION   PRIORITY       SITE        AGE  FAIRSHARE    JOBSIZE  PARTITION
629777 skylake         1633          0       1386        247          0          1
629777 cascade         1633          0       1386        247          0          1
629977 cascade         1367          0        626        741          0          1
629977 skylake         1367          0        626        741          0          1
630001 skylake         1501          0        760        741          0          1
630001 cascade         1501          0        760        741          0          1
630002 skylake         1500          0        759        741          0          1
630002 cascade         1500          0        759        741          0          1
630003 skylake         1499          0        758        741          0          1
630003 cascade         1499          0        758        741          0          1
630004 skylake         1499          0        758        741          0          1
630004 cascade         1499          0        758        741          0          1
630005 skylake         1499          0        758        741          0          1
630005 cascade         1499          0        758        741          0          1
630018 cascade         1480          0        738        741          0          1
630018 skylake         1480          0        738        741          0          1
630109 skylake         2303          0        574       1728          0          1
630121 skylake         2287          0        558       1728          0          1
630122 skylake         2281          0        553       1728          0          1
630171 cascade          885          0        391        494          0          1

Comment faire pour que mon job commence plus tôt ?

  • S’il y a suffisamment de ressources libres, votre travail démarrera très prochainement. Pour vérifier le moment prévu par le gestionnaire des tâches, vous pouvez faire

scontrol show job JOBID

et trier sur la variable StartTime

Dans l’exemple ci-dessous le job 630171, soumis le 28 janvier 2022 à 21:49:48, est en attente sur la partition cascade :

JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
630171   cascade 64_2304l laadhari PD       0:00      2 (Priority)

et la commande

scontrol show job 630171 | grep StartTime

renvoie une date et horaire de démarrage au plus tard le 30 janvier 2022 à 18:23:01

StartTime=2022-01-30T18:23:01 EndTime=2022-02-06T18:23:01 Deadline=N/A
  • Si la machine est utilisée intensivement par d’autres utilisateurs (ou par vos travaux), SLURM exécutera votre travail dès qu’il y aura suffisamment de ressources libres. Assurez-vous de ne demander que la ressource dont vous avez besoin : plus vous en demandez, plus vous et les autres utilisateurs attendrez.

Vous pouvez vérifier l’usage des ressources d’un job terminé avec la commande seff

seff JOBID

vous permet de mieux d’ajuster a posteriori les ressources en temps et mémoire à réserver pour un prochain job identique.

Pourquoi mon job s’est arrêté alors que mon calcul n’est pas fini ?

Causes probables

Il peut y avoir de nombreux facteurs qui conduisent à l’interruption d’un job. Parmi les causes possibles : * le job dépasse la limite des ressources spécifier dans le fichier de soumission en terme de durée d’exécution, de taille mémoire ou des deux * la durée d’éxécution du job est plus longue que prévue car il y a un soucis sur les noeuds où il s’exécute * le code exécuté par le job réalise des écritures sur disque mais votre quota est dépassé * les fichiers ne peuvent être écrits ou lus car il y a un soucis dans le serveur NFS qui vous permet d’écrire sur les espaces disques depuis les noeuds

Solutions possibles

  • Modifier les demandes de ressources en terme de temps et de mémoire

  • Vérifier votre quota de disques

  • Signaler tout au problème à l’équipe d’aministration de la machine

sbatch error: Socket timed out on send/recv operation

Causes probables

Ce message peut apparaître lorsque la charge sur le planificateur de tâches est trop élevée.

Solutions possibles

L’équipe technique travaille à minimiser les indisponibilités du contrôleur du SLURM. Actuellement, celui-ci étant accessible sur les partitions via un montage NFS, sa disponibilité dépend essentiellement de la charge sur le réseau des machines de prepost-, qui elle-même dépend très largement de l’usage interactif de ces machines, lorsqu’ils exploitent l’accès aux volumes partagés.

Mon job plante avec le message Illegal instruction

Causes probables

L’exécutable que vous avez utilisé a été construit ou appelle des bibliothèques qui ont été contruites pour une architecture différente de celle de la machine où vous avez lancé votre job.

Cela peut arriver par exemple lorsque vous chargez les modules contruits pour haswell alors que vous utilisez un noeud cascade, par exemple.

Solution possible

Il suffit a priori de construire l’exécutable avec les modules associés à l’architecture sur laquelle vous soumettez le job et de lancer votre job avec cet environnement.