Bonjour à tous,
Je remarque un problème avec le lancement de Blobtools sur la partition "long" depuis la mise à jour du serveur...
A chaque lancement de mon script, la commande produit des fichiers core.* d'une taille variable entre 0 et 30Mo (1 fichier par séquence analysée) et ne sort plus le résultat de celle-ci dans les fichiers demandés. Normalement, pour chaque séquence analysée par blobtools, un fichier contenant des séquences semblables identifiées par blast dans la DB nt est créé et rempli. Ici ils sont tous vides... Même ceux dont je connais déjà le résultat ! (La commande avait été interrompue pour la MAJ du serveur)
Auriez-vous une idée de la raison pour laquelle se problème se produit ?
Je précise que je n'ai pas modifié mon script entre la première fois où la commande a été lancée (avant MAJ) sans qu'aucun problème ne soit rencontré, et maintenant.
Le job ne se termine qu'une fois la mémoire du projet dépasse celle allouée (+300Gb occupé par les core.*).
Ligne du script correspond à blobtools :
List_fasta=$(ls ${tmp_folder}/fasta/*fa)
parallel --ungroup --jobs 10 diamond blastx -b8 -c1 -q {} -d /shared/bank/nr/nr_2022-1-30/diamond/nr -o {}.blastout -p $SLURM_CPUS_PER_TASK -f 6 qseqid staxids bitscore ::: $List_fasta
En vous remerciant par avance de votre aide,
Aurélie
Bonjour Aurélie,
Je ne suis pas sûr de bien comprendre le problème.
Si vos commandes ont été interrompu par l'arrêt du cluster, il me paraît plus sage (si possible) de nettoyer les fichiers éventuellement créés et de relancer les jobs en question.
Vos jobs actuellement se terminent en erreur ("out of memory") il me semble donc pas anormal que les fichiers résultats soient vides. Peut-être simplement essayer en augmentant la mémoire jusqu'à 250G, voire en utilisant bigmem.
Mais je ne suis pas sûr de comprendre la différence avant/après l'arrêt du cluster.
J'ai quand même une remarque, qui peut peut-être expliquer la longueur du job utilisé voire la mémoire demandée.
La commande, "parallel --ungroup --jobs 10 diamond blastx [...] -p $SLURM_CPUS_PER_TASK [...]", me semble pas bonne. Si je comprends bien la commande lance 10 processus "diamond blastx ...", et chaque process va utiliser "$SLURM_CPUS_PER_TASK" thread (soit pour 20 CPU demandés, 20 threads pour chaque commande lancé par parrallel). Ce qui au final, lancerais 10*20=200 threads sur les 20 CPU. Ce qui serait contre-productif.
Intuitivement j'aurai juste lancé la commande sans la parallel "diamond blastx -p $SLURM_CPUS_PER_TASK [...]", et pour chaque fichier fasta a traiter, lancé un job.
1 « J'aime »
Merci beaucoup pour votre aide, je vais essayer de jouer avec la mémoire dans ce cas et suivre vos conseils sur les threads.
Merci encore !
Aurélie