Je note que les tâches demandant les nœuds GPU ipop-up 15-18 sont bloquées en attente « PD » i.e. (ReqNodeNotAvail, UnavailableNodes:gpu-node17)
Il est très probable que c’est moi qui a tout planté. J’ai essayé de lancer un screen alphafold2 sur ces nœuds et seulement 9 tâches ont complété avant que les autres se bloquent en « PD ».
J’ai annulé mes jobs slurm, mais malheureusement, je pense que les nœuds sont toujours bloqués car une autre job d’un autre utilisateur : 19400947 ipop-up RNA_3_5_ meuret PD 0:00 2 (ReqNodeNotAvail, UnavailableNodes:gpu-node17)
est toujours bloquée.
J’avais réussi à exécuter le même screen alphafold2 le mois dernier avec un minimum de problème, je ne sais donc pas exactement quelle pourrait être la cause. Mes plates excuses si je suis effectivement la cause.
Oui, dans Slurm, le message “Kill Task Failed” signifie que Slurm a tenté de tuer un processus mais n’a pas réussi, et donc il place le noeud en status DRAINED.
La commande est: /shared/projects/ht-colabfold/ht-colabfold/alphafold_batch.sh -O /shared/projects/ht-colabfold/H1/output -1 /shared/projects/ht-colabfold/H1/H1.4.fasta -2 /shared/projects/ht-colabfold/H1/2025-11-18_ChromatinProteinsUnion.filt_500.fasta
La différence entre mes jobs qui n’ont pas planter les noeuds vs ces jobs plus récents est que j’ai passé de:
Mais je suis confus, car j’ai également remarqué que les jobs étaient bloquées sur “PD”, mais ce n’est plus le cas aujourd’hui et elles semblent s’être exécutées avec succès:
Avez-vous annulé les tâches ? Je pose cette question simplement pour mieux comprendre le comportement de ces tâches/slurm, ça ne me dérange absolument pas que mes tâches moches aient été annulées.
Non, je n’ai pas tué de jobs. Vos jobs étaient bloqués en status PENDING parce que les 3 noeuds GPU étaient en status DRAINING (à cause de l’erreur Kill Task Failed) et donc n’acceptaient plus de jobs. Lorsque je les ai remis en service, vos jobs ont été exécutés.
Si vous les avez toujours, il me faudrait les id des jobs qui ont planté et provoqué le “Kill Task Failed”, ainsi que les logs de slurm, afin que je puisse investiguer.
Intéressant… c’est bizarre que les jobs plantes les gpus lorsqu’ils sont soumis mais pas après un reboot. Je ne vais plus lancer de jobs.
En fait, comme ht-colabfold n’est autre que AF2 qui gère la soumission des tâches dans Slurm, j’ai du mal à trouver les sorties Slurm et les identifiants de tâche.
Je n’ai pas reboot les noeuds, je les ai simplement remis dans la queue.
Ah d’accord.
Entre le plantage et le non-plantage, la seule différence que je vois, c’est qu’au lieu d’utiliser toutes les partitions A100 (y compris celles de 20 Gb), je n’ai utilisé que celles de 40 et 80 Go, ce qui a peut-être surchargé les partitions ? Je ne comprends pas bien les étapes impliquées, mais je suppose que c’est SLURM qui surcharge le système quand il y a moins de partitions.
J’ai également remarqué un bug où ht-colabfold a échoué pour certaines prédictions. Je me demande s’il utilise les partitions plus petites de 20 Go pour les prédictions de complexes protéiques de grande taille… L’intérêt de ht-colabfold est qu’il distribue les tâches de manière intelligente, mais il n’est peut-être pas configuré correctement de mon côté…
Il ne peut pas y avoir de phénomène de surcharge sur les instances gpu, slurm n’alloue qu’une seule instance par job.
Je n’ai pas bien compris comment fonctionnait votre pipeline mais le plus propre serait de sélectionner l’instance gpu en fonction de la taille de votre système (celles de 80gb étant réservées aux plus gros).
Le probleme pourrait peut être venir de la taille des séquences utilisées ? Si les séquences sont trop grosse (+ 2000-3000 residues pour le complexe modélisé) sa pourrait expliquer le plantage.
Ca vaudrait peut etre le coup d’utiliser AlphaPulldown, qui a l’air de faire la meme chose, si j’ai bien compris, que colabfold-ht.