Queue des jobs en gpu

opem · Avril 30, 2024, 11:45

Bonjour,

J'aimerais comprendre le fonctionnement de la queue pour l'utilisation des gpu de l'IFB. J'utilise alternativement les commandes 'sinfo -N -O nodelist,partition:15,Gres:30,GresUsed:50 -p gpu'
et 'squeue -p gpu' pour voir l'utilisation courante des gpu et la queue pour lancer des jobs, cependant je ne comprends pas tout... Il y a des fois ou il n'y a rien d'autre dans la queue et le gpu que je demande est libre, pourtant le job ne se lance pas.

Y a-t-il une restriction sur leur utilisation si j'ai déjà d'autres jobs qui tournent en gpu ? (j'ai pourtant déjà réussi à lancer des jobs gpu en simultané). Si j'ai bien compris, il ne faut pas demander plus de cores cpu que disponibles sur un même noeud gpu (j'ai déjà réussi à lancer deux jobs gpu en simultané sur les deux gpu 40g du noeud 3 en calculant le nombre de cores restant pour lancer mon deuxième job, sinon cela ne fonctionnait pas...), ai-je bien compris ? Y a-t-il un moyen de consulter le nombre de cores actuellement utilisé sur chaque noeud gpu ?

Globalement, comment fonctionne l'attribution des gpu ? Toute aide est la bienvenue !

Merci beaucoup d'avance pour votre temps,
Bonne journée,
Mathieu

dbenaben · Mai 2, 2024, 5:39

Bonjour,

Si les ressources (GPU, CPU, mémoire) sont disponibles, votre job doit être lancé.
Si ce n'est pas le cas, c'est une erreur et n'hésitez pas à nous le signaler.

Les ressources GPU sont assez limité et ont été découpées en plusieurs profils (SLURM GPU - IFB Core Cluster Documentation):

gpu-node-01: 14 profils 1g.5gb
gpu-node-02: 2 profils 3g.20gb
gpu-node-02: 1 profil 7g.40gb
gpu-node-03: 2 profils 7g.40gb

Il est donc possible que des cartes/noeuds GPU soit disponibles si des profils ne sont pas utilisés (le petit profil 1g.5gb est souvent disponible).

Je pense également que dans votre cas, ce ne sont pas les ressources GPU qui ont "bloqué" en attente votre job mais les autres ressources: CPU ou mémoire.
En occurrence, je vous rejoins, ce sont sûrement les CPU qui n'étaient pas disponibles.
Sur un noeud GPU de l'IFB on a 62 CPU et 500G de mémoire pour le calcul. Je ne peux donc pas avoir 2 jobs demandant chacun 1 profil 7g.40gb, 128G RAM et 32 CPU. Le deuxième job reste en attente puisqu'il y a seulement 30 CPU disponibles (il attend qu'ils soient libérés).

Pour visualiser les ressources CPU, mémoire et GPU, on peut toujours faire appel à la commande sinfo:

# List of node names.
# Number of CPUs by state in the format "allocated/idle/other/total"
# Size of memory per node in megabytes.
# Amount of allocated memory on a node
# Generic resources (gres) associated with the nodes.
# Generic resources (gres) currently in use on the nodes.

sinfo -N -O nodelist,CPUsState,Memory:10,AllocMem,Gres:30,GresUsed:50 -p gpu

Et comme vous le notez, on peut utiliser la commande squeue pour visualiser la file avec plein d'infos complémentaires:

squeue -p gpu -O "JobID:10,UserName:10,State:10,TimeUsed:10,TimeLimit:15,NumNodes:6,NumCPUs:5,MinMemory:15,tres-per-node,NodeList:15,Reason"

Faites-nous signe si cela bloque.

Bonne soirée

dbenaben · Mai 3, 2024, 8:02

J'oubliais: pensez à bien vérifier que la demande en ressource (GPU, CPU, mémoire) corresponds bien à ce qui est utilisé (pour éviter de gaspiller des ressources), par exempla à l'aide de seff une fois votre job terminé (SLURM user guide - IFB Core Cluster Documentation).

opem · Juin 20, 2024, 8:39

Bonjour,

Je reviens vers vous car j'ai beaucoup de mal à accéder à des cartes gpu en ce moment. Pour exemple, le screen ci-joint, j'essaye de demander l'accès aux cartes 3g.20gb et 1g.5gb (mes jobs sont ceux opem) mais rien ne bouge, pourtant la queue est quasiment vide et il y a une 3g20gb de disponible (et le node 1 est vide). Globalement je n'ai pas eu accès à un gpu depuis le début de semaine alors que certains étaient disponibles lorsque j'en faisais la demande, je ne sais pas s'il y a un problème avec mon compte ? Je fais pourtant attention au nombre de cpu et à la quantité de mémoire que je demande, et qui sont censés être disponibles à chaque fois. Même pour les cartes 1g5gb je n'arrive pas à y accéder (en job SLURM ou via jupyterLab), alors qu'il y en a toujours de disponible.

Merci beaucoup par avance pour votre aide,
Bonne journée,
Mathieu

opem · Juin 20, 2024, 2:33

Je confirme qu'il doit y avoir un problème avec mon compte, le job avec les exactes mêmes spécificités lancé après coup par mon collègue (compte gwenaellumet) a accédé au gpu tandis que le mien est toujours en attente. Je n'ai pas pu accéder à un gpu depuis Lundi.

dbenaben · Juin 20, 2024, 4:54

Je constate aussi des anomalies.
Mais pour l'instant je ne trouve pas la cause.
On continue à fouiller.

opem · Juin 24, 2024, 8:32

Bonjour,

Désolé de revenir vers vous mais le problème est toujours d'actualité et vraiment handicapant... (ici le noeud 2 est vide et j'ai lancé plusieurs jobs jupyterlab avec des specs différentes pour essayer d'accéder à un gpu mais rien ne se lance et tout reste dans la queue, avec le noeud 2 qui reste vide)

Désolé pour le dérangement,
Merci d'avance pour votre aide

Mathieu

dbenaben · Juin 25, 2024, 3:11

Bonjour @opem

Deux noeuds GPU (gpu-node-02, gpu-nde-03) ont été marqué "drain" (slurm n'accepte plus de nouveau jobs) afin de nous permettre de mettre à jour le driver CUDA

$ sinfo -Nel -p gpu
Tue Jun 25 17:05:58 2024
NODELIST     NODES PARTITION       STATE CPUS    S:C:T MEMORY TMP_DISK WEIGHT AVAIL_FE REASON              
gpu-node-01      1       gpu       mixed 62     2:31:1 505440        0     10   (null) none                
gpu-node-02      1       gpu    draining 62     2:31:1 505440        0     10   (null) update cuda driver  
gpu-node-03      1       gpu    draining 62     2:31:1 505440        0     10   (null) update cuda driver

Désolé pour le désagrément.

dbenaben · Juin 27, 2024, 1:08

La maintenance est terminée. Les noeuds sont a jours.

https://community.france-bioinformatique.fr/t/cuda-driver-updated-to-version-12-4/

opem · Juin 27, 2024, 1:13

Bonjour @dbenaben,

Désolé de revenir vers vous, je pense que le problème n'était pas lié à la maintenance des noeuds 2 et 3, je n'arrive toujours pas à accéder à des cartes gpus alors que certaines sont disponibles (même en SLURM, et même sur les 14 cartes 1g.5gb qui sont quasiment toutes toujours disponibles, auxquelles je n'arrive pas à accéder pendant des jours...). Encore à l'instant j'étais le seul dans la queue pour obtenir la 3g.20gb qui était disponible (et les cpus / mémoire que j'ai demandé l'étaient aussi), mais je suis resté en queue, un autre utilisateur est arrivé quelques dizaines de minutes après et y a accédé directement... Ou alors il y a quelque chose que je ne comprends pas sur l'accès aux gpus.

Encore désolé de vous déranger avec ça, mais pour l'instant c'est notre seul moyen d'accéder à des gpus dans notre labo, ce qui rend la situation assez handicapante.
Merci beaucoup d'avance pour votre aide !
Mathieu

dbenaben · Juin 27, 2024, 1:38

Bonjour,

En effet, je ne m'explique pas bien certains comportement (jobs soumis avant mais pas exécuté...).
On regarde

opem · Juin 27, 2024, 1:40

Merci beaucoup !

opem · Juin 28, 2024, 9:42

Bonjour @dbenaben,

Pour information, j'ai dis précédemment que je pensais qu'il y avait un problème avec mon compte, mais d'après mes derniers tests, il semblerait que ce soit un problème de projet plutôt que de compte. En lançant des jobs JupyterLab avec les mêmes specs en demandant une carte 1g.5gb, le job sous le projet "comet" reste en queue indéfiniment alors que celui sous le projet "breast_pathology_img" se lance directement. Il semble donc y avoir un problème avec le projet "comet", avec lequel nous avons pourtant beaucoup travaillé sur les noeuds gpu depuis avril...

Si cela peut aider dans votre recherche de solution,
Merci beaucoup,
Bonne journée

dbenaben · Juillet 1, 2024, 9:01

Bonjour,

Nous avons continué nos tests.

Concernant le compte comet, en effet, ce dernier n'est pas toujours prioritaire.
Après consultation des grands sages (merci @team.ifbcorecluster), c'est "normal".
C'est dû au mécanisme de FairShare (Slurm Workload Manager - Fair Tree Fairshare Algorithm).
Le FairShare est une valeur calculée en fonction de l'usage du cluster (nombre heure de calcul et efficacité des jobs).
Cette valeur est alors affectée à chaque jobs et rentre dans le calcul de priorité des jobs.
La priorité du job prends en compte l'age du job (depuis quand il est en attente), le FairShare et la partition.
Dans notre config, le poids du FairShare est plus important que l'âge du job.

Ainsi, lorsque que l'on a beaucoup calculé (usage important du cluster) ou lancé des jobs inefficace (on réserve "30 CPU, 300Go RAM", mais on utilise que "10 CPU, 20 GO RAM"), la valeur du FairShare baisse et on peut voir les jobs d'autres utilisateurs exécutés avant nous.

Concernant les ressources, on observe parfois des ressources qui semblent disponibles mais marquées "Priority". C'est que cette ressource n'est en fait pas disponible parce qu'elle est déjà prévue pour un autre job.

J'espère que ça éclaircit un peu le fonctionnement.

PS: @opem pouvez-vous répondre à mon message privé ?

dbenaben · Juillet 1, 2024, 9:27

PS: nous constatons encore quelques anomalies, on continue de regarder.