Jobs pending et priority

IFB Core Cluster
1

Bonjour,
Cela fait un moment que je me pose cette question. Je n'ai toujours pas compris comment les regles de priorité fonctionnent pour les job.
J'essaie de lancer un script de basecalling (guppy)
Il n'y a actuellement qu'un seul job running sur le node gpu-node-02
Je m'attendais donc, vu qu'il n'y a pas vraiment la queue, que le job que je lance se lance quasi immédiatement.
Et pourtant, ce n'est pas le cas, il doit donc y avoir quelque chose qui m'échappe...
Il y a donc un job running sur gpu-node-02
j'ai essayé de lancer le mien sur les 3 (en 3 jobs différents bien sûr)
#SBATCH --gres=gpu:7g.40gb:1
#SBATCH --gres=gpu:3g.20gb:1
#SBATCH --gres=gpu:1g.5gb:1
Mais aucun ne s'est lancé ...

quelqu'un peut-il m'expliquer comment ces priorisations fonctionnent ?
J'ai entendu parler de l'algorithme fairshare mais il me semble que c'est un algorithme de priorisation dans la queue. S'il n'y a pas la queue, cela ne devrait pas intervenir ?

Je n'ai en effet pas énormément d'expérience sur l'utilisation du cluster et il est possible que je doive lancer (souvent) des petits scripts sur des petits jeux de données pour me familiariser à l'utilisation.

Merci de votre retour

2

Juste pour préciser (je n'ai pas trouvé de bouton d'édition de mon message précédent):
Bien sûr j'ai demandé 'activation de la partition gpu pour mon projet et j'ai déjà eu des scripts qui se lancent. Je ne comprend juste pas les règles de priorisation et d'attente au lancement des scripts.
Merci

3

Bonjour,

Contrairement aux CPU, les ressources GPU sur l'IFB ne sont pas nombreuses: https://ifb-elixirfr.gitlab.io/cluster/doc/slurm/slurm_at/#gpu-nodes

De plus, des serveurs peuvent être indisponible (drain) pour maintenance. Comme ici pour le gpu-node-03:

$ sinfo -Nl -p gpu
Tue Oct 22 16:25:42 2024
NODELIST     NODES PARTITION       STATE CPUS    S:C:T MEMORY TMP_DISK WEIGHT AVAIL_FE REASON              
gpu-node-01      1       gpu        idle 62     2:31:1 505601        0     10   (null) none                
gpu-node-02      1       gpu       mixed 62     2:31:1 505440        0     10   (null) none                
gpu-node-03      1       gpu     drained 62     2:31:1 505440        0     10   (null) upgrade.ubuntu

Du coup, il y a peu de ressource et elles sont assez souvent sollicitées (du coup, nos jobs restent "pending").

Il est possible de voir qu'elles ressources (profil GPU) sont disponibles via quelques commandes. Plus d'info, ici: Disponibilité des noeuds GPU?

En bref, il y a bien une priorisation (fairsharing) mais sur les noeuds GPU, je doute que cela se ressente. Ce qui est bloquant est le nombre de ressource disponible.

Bonne journée

4

Je constate aussi que parfois les job sont en attente alors que la ressource est disponible. Hier j’utilisai 1 GPU sur le node-02 mais ma collègue n’arrivai pas a avoir la seconde carte... et ce n'était pas les ressources CPU et RAM qui bloqué....
je voudrai aussi vous préciser que le node-01 n'est jamais utilisé car 5G de mémoire et trop peux pour les job GPU et aucun job ne parviens a fonctionner. Serai-t-il envisageable de partitionner le node-01 comme le node-02?

5

j’utilisai 1 GPU sur le node-02 mais ma collègue n’arrivai pas a avoir la seconde carte... et ce n'était pas les ressources CPU et RAM qui bloqué....

Je ne reproduis pas ce problème (j'arrive bien à positionner un job sur chaque carte / MIG).
Avez-vous un numéro de job ou l'id de votre collègue à nous indiquer pour qu'on regarde ?

je voudrai aussi vous préciser que le node-01 n'est jamais utilisé car 5G de mémoire et trop peux pour les job GPU et aucun job ne parviens a fonctionner.

Il me semble que c'est utilisé.
A minima, pour mettre au point son traitement ou avoir un job interactif sur GPU (JupyterHub).
Nous devrions revoir le partitionnement des GPU (après les maj Slurm en cours). Nous en rediscuterons alors.