Je pense que j'ai peut-être un problème avec l'espace alloué à mon compte (dils_oedulis). J'obtiens toujours cette erreur lorsque j'essaie d'exécuter un travail :
slurmstepd-cpu-node-2: error: Detected 1 oom_kill event in StepId=43107790.batch. Some of the step tasks have been OOM Killed.
J'ai consulté de nombreux messages dans ce forum communautaire et le conseil semble être d'augmenter la mémoire demandée pour le travail. J'ai fait cela plusieurs fois, même jusqu'à 500G, mais le travail ne s'exécute toujours pas. Cela me surprend également qu'il faille autant de mémoire, et c'est inquiétant parce que j'ai besoin d'exécuter le job sur un fichier plus gros une fois que je l'aurai fait fonctionner. Je vois que mon projet a très peu de mémoire restante, peut-être est-ce la cause du problème ?
Merci beaucoup pour votre aide et je m'excuse si j'ai oublié quelque chose sur un forum quelque part ! Je m'excuse également pour les fautes de français.
En regardant un peu plus, j'ai l'impression que vous lancez un workflow avec snakemake.
Lorsque vous lancez ce worflow, vous demandez en effet bcp de mémoire (500G).
Ce workflow va alors lancer un autre job, qui lui aura 40G de mémoire et va échouer avec l'erreur "Out Of Memory (OOM)".
Le workflow lancé précédemment s'arrête alors ("Failed").
Il faut donc augmenter la mémoire du job lancé par snakemake et non la mémoire du job "snakemake".
Tout au mois, j'ai l'impression que c'est ça.
Vous pouvez nous donner les scripts en questions si ça ne fonctionne toujours pas.
Merci beaucoup pour votre solution précédente, elle m'a été très utile ! Cependant, j'utilise à nouveau un fichier plus volumineux et j'ai rencontré des problèmes de limite de temps à l'une des étapes (« modelComparison »). Je me suis rendu compte qu'il fallait que mon fichier de configuration json autorise les tâches longues de plus de 24 heures. J'ai donc modifié le début de mon fichier json comme suit :
Mais maintenant, le problème est que le travail s'exécute incroyablement lentement (il n'a pas dépassé l'étape 1 depuis jeudi), ce qui me fait penser que j'ai peut-être fait quelque chose de mal.
Pourriez-vous me conseiller sur ce qui pourrait être le problème ?
Merci beaucoup pour votre aide et votre patience !
Difficile à dire plus sans plus de détail (c'est quoi l'étape "1", lent par rapport à quoi ?, lent à l'exécution ou pending ? etc).
Il faut nous donner le maximum d'élément et le jobid.
Vous lancer un job (45589207) avec 1 CPU et 50Go RAM qui ne fait rien (CPU=0.0%, MEM=0%), est-ce vraiment nécessaire de monopoliser 50G RAM et même 1 CPU ?
Vous avez ensuite un job (45589209) qui s'est exécuté en (8 minutes) et une centaine de jobs avec un time limit de 2j sur la partition fast:
Ces jobs ne seront jamais exécutés puisque vous demandez la partition fast et un timelimit de 2 jours.
Ils restent donc en attente en raison de la PartitionTimeLimit.
Théoriquement, ils pourraient être lancé si un administrateur augmente le temps maximal pour la partition (du coup slurm attends). Mais on ne fait jamais ça.
Il faut donc ajuster le timelimit de vos jobs (ou changer pour la partition fast).
Je pense que je dois être confus/manquer quelque chose. Je m'excuse car je suis nouveau dans l'utilisation de snakemake et de ce cluster.
Et je suis désolé de devoir préciser que maintenant il semble démarrer l'étape « modelComparison » mais ne crée jamais de sortie. Avant d'ajuster les paramètres par défaut, l'étape « modelComparison » s'exécutait, créait de nombreux fichiers de sortie et finissait par se planter lorsqu'elle n'avait plus de temps.
Je m'excuse si je demande trop d'espace/temps pour des tâches simples, je n'arrêtais pas de manquer de temps et d'espace et j'ai donc pensé que je devais les augmenter, pourriez-vous me conseiller sur les meilleures limites d'espace/temps à demander ?
Je n'y connaît pas grand chose en snakemake mais peut-être que @team.workflow pourra vous aider.
pourriez-vous me conseiller sur les meilleures limites d'espace/temps à demander ?
Malheureusement, il n'y a pas de secrets.
Côté CPU, il faut simplement demander autant de CPU que de threads/process (option des programmes).
Côté RAM... c'est l'expérience, l'essai/erreur ou la vérification en cours ou une fois son job terminé qui permets d'ajuster.
Côté temps... idem. L'expérience ou par essai/erreur.
Plus d'infos: SLURM job efficiency - IFB Core Cluster Documentation