Bonjour,
Depuis hier j'ai rencontré des problèmes quand je lance le script.
Le job est "submitted" mais "Failed" sans output.
Par contre quelque fois il a réussi à lancer, et c'est toujours sur le meme script je teste, je ne modifie que le --mem.
Je suis en train de custumiser une database de Kaiju qui a besoin d'un certain nombre de RAM (je ne sais pas le nombre exacte).
Au début j'ai testé avec 100GB de mem il a été arrété car "OUT_OF_ME+", meme raison pour 150GB et 200GB.
Pour l'instant j'ai réussi à lancer le job mais il est toujours en PD et en attendant de ressources ("--exclusive" cette fois).
Je met mon script au dessous:
#!/bin/bash
#SBATCH --partition=fast
#SBATCH --ntasks=1
#SBATCH --nodes=1
##SBATCH --mem=150GB
##SBATCH --time=0-04:00
#SBATCH --cpus-per-task=32
#SBATCH -o result/kaiju_output/slurm.%N.%j.out
#SBATCH -e result/kaiju_output/slurm.%N.%j.err
#SBATCH --job-name=kaiju_build
#SBATCH -A viropip
#SBATCH --exclusive
# Working directory
cd /shared/projects/viropip
module load kaiju
##module load krona
echo "viropip kaiju"
kaiju-mkbwt -n 32 -a ACDEFGHIKLMNPQRSTVWY -o databases/uniref90/uniref90 databases/uniref90_noPlantMetazoa_format.faa
Je ne sais pas s'il arrivera à finir sans erreur, mais je voudrais savoir si quelqu'un pourrait me dire les raisons possibles dans le cas où "job submitted" mais Failed toute suite pour éviter que je re fasse les memes erreurs.
Merci d'avance,
juejun
Bonjour,
Si il n'y a aucun fichier de sortie créé et que le job échoue immédiatement, c'est souvent un problème avec les paramètres.
Ca semble le cas ici, puisque le dossier result/kaiju_output n'existe pas (par exemple pour votre job 31831844), il ne peut alors créer le fichier de sortie:
[31831844.batch] error: Could not open stdout file /shared/ifbstor1/projects/viropip/databases/result/kaiju_output/slurm.cpu-node-42.31831844.out: No such file or directory
[31831844.batch] error: IO setup failed: No such file or directory
Les autres jobs ont l'air de bien tourner et finisse simplement avec une erreur renvoyé par la commande exécuté (FAILED, task 0 (37330) exited with exit code 1) ou un manque de mémoire (OUT_OF_MEMORY).
Faites-nous signe si ça bloque encore (une fois les dossiers créés ou le chemin corrigé).
Merci pour votre réponse, j'ai bien re vérifier les chemins, il a bien marché!
Mais concernant le manque de mémoire, je voudrais demander s'il est possible d'utiliser bigmem pour le projet viropip? Parce que j'ai besoin plus de RAM pour construire ce DB ou faire une classfication taxonomique contre une grande DB par mmseqs2.
Merci beaucoup,
Pouvez-vous tester au préalable en utilisant toute la mémoire des noeuds standard (250G max) ?
Pour construire le DB de kaiju, j'ai testé avec --exclusive, si j'ai bien compris, il utilise déjà la mémoire max d'un noeud?
Et pour mmseqs, il est arrété à cause de OUT OF TIME en utilisant avec 200G, je suppose avec 250G il sera aussi arrété pour la même raison... c'est pour ça je voudrais utiliser bigmem pour pouvoir réduire un peu le temps de calcul.
En effet, --exclusive utilise normalement tout la mémoire d'un noeud mais pour kaiju je ne vois qu'un test avec 200G. Le dernier test utilise seulement 2G. Pouvez-vous essayer en spécifiant explicitement --mem 250G ?
Pour mmseq, à priori, ce n'est pas un problème de mémoire (FAILED, exited with exit code 1). C'est le programme qui échoue. Ce n'est pas par manque de mémoire.
On peut vérifier la mémoire utilisée avec la commande seff. Par exemple:
$ seff 31903565_622
Job ID: 31903565
Array Job ID: 31903565_622
Cluster: core
User/Group: jchen/jchen
State: FAILED (exit code 1)
Nodes: 1
Cores per node: 32
CPU Utilized: 2-10:16:12
CPU Efficiency: 75.98% of 3-04:41:36 core-walltime
Job Wall-clock time: 02:23:48
Memory Utilized: 133.87 GB
Memory Efficiency: 66.94% of 200.00 GB
Je vous ai quand même donnée accès à la partition bigmem pour le projet viropip mais je vous invite à tester avant sur les noeuds standards et à bien vérifier l'usage réel avant d'augmenter la mémoire demandée.
D'accord, merci. Je vais le re tester sur les noeuds standards en spécifiant le nombre de RAM avant utiliser bigmem.
Job ID: 31858780
Array Job ID: 31858780_589
Cluster: core
User/Group: jchen/jchen
State: TIMEOUT (exit code 0)
Nodes: 1
Cores per node: 32
CPU Utilized: 00:01:12
CPU Efficiency: 0.00% of 32-00:05:52 core-walltime
Job Wall-clock time: 1-00:00:11
Memory Utilized: 114.87 GB
Memory Efficiency: 57.44% of 200.00 GB
et c'est pour ce job il a été arrété à cause de TIMEOUT et je cherche à comprendre comment réduire un peu le temps de calcul.
TIMEOUT signifie que le job dépasse le temps demandé (option --time).
Dans le job ci-dessus, le temps demandé et alloué était de 1j ( 1-00:00:00).
Le job étant toujours en train de s’exécuter après 1j, il a été tué.
Il est tout à fait possible de demander plus de temps (option --time).
A noter alors (et à l'heure actuelle) que si le job doit tourner plus d'une journée, il faut basculer sur la partition dite long: SLURM at IFB Core - IFB Core Cluster Documentation (option --partition=long).
Mais pour le job en question, je pense que le problème est ailleurs.
On peut voir que le job n'a quasiment pas utilisé de CPU (0% des 32 CPU).
Et que la mémoire ne sature pas du tout (114Go utilisé / 200Go).
La taille du job (en mémoire ou CPU) ne changera probablement donc rien.
C'est même pas très correct puisqu'on bloque 32CPU (et 200Go de mémoire) pendant 24h sans les utiliser.
Peut-être re-essayer avec moins de CPU/RAM mais plus longtemps.
Mais j'ai le sentiment que le problème n'est pas sur la taille/temps du job.
Un CPU quasiment à 0 indique que le programme "attends" (ou qu'il ne marche pas).
Par exemple, si le programme récupère des données depuis Internet mais que le serveur distant ne lui envoi les données qu'à quelques ko... le programme ne calcul rien, il attends les données.
Il faut donc rentrer un peu dans le détail pour voir ce qui coince.