Processus stoppé sans raison

IFB Core Cluster
1

Bonjour à la team,

Je fait tourner une commande QIIME2 qui fonctionne bien avec une base de données relativement petite (ITS) mais quand je passe un un fichier plus gros (16S), la fonction tourne, je la vois progresser (--verbose) mais beaucoup plus lentement et au bout de 2h-2h30... disparition du job... sans message d'erreur.
Est-il possible d'accéder à mes "log" qui pourrait me donner un indice sur ce qu'il se passe ?
Voici ma ligne de commande :
srun --mem-per-cpu=16GB qiime dada2 denoise-single --i-demultiplexed-seqs seq_single_end_16S.qza --p-trunc-len 0 --output-dir dada2_denoise --verbose

la commande danoise single a cette option :
-p-n-threads INTEGER The number of threads to use for
multithreaded processing. If 0 is provided,
all available cores will be used. [default:
1]
Est-ce que cela pourrait m'aider à accélérer mon job?
Si oui merci de m'aider à l'utiliser dans SLURM si possible pour faire du threading je ne sais pas faire.

Merci de vos réponses par avance !

Mathias

2

Bonjour Mathias,

Difficile de dire ce qui coince sans message d'erreur... Rien dans la console/sortie de qiime2 ?

Pour avoir plus d'information sur un job, il est possible d'utiliser la commande scontrol show job <jobid> (le jobid est l'identifiant renvoyé par sbatch, aussi visible avec squeue). Mais dans notre cas, avec srun, ce n'est pas utile.

Pour ce type de traitement, je vous inviterais plutôt à utiliser la commande sbatch.
Le fonctionnement est similaire à srun mais non interactif.
Cela à plusieurs avantage: exécution en arrière plan, on garde une trace du traitement effectué, possibilité d'utiliser les JobArray, etc.

Il faut alors écrire un petit script bash avec la ou les commandes à exécuter.
Nommons ce script denoising.sh:

#!/bin/bash
#SBATCH --mem-per-cpu=16GB

module load qiime2/r2019.01

qiime dada2 denoise-single --i-demultiplexed-seqs seq_single_end_16S.qza --p-trunc-len 0 --output-dir dada2_denoise --verbose

On peut alors l'exécuter:

sbatch denoising.sh

Et suivre l'exécution du job en regardant le fichier résultat slurm-<jobid>.out ou la commande squeue.

En effet, l'utilisation de "threads" permets d'accélérer le traitement.
Il en faut pas hésiter à l'utiliser dès que possible (i.e. dès que le logiciel a une option pour parraléliser le traitement, on parle alors de "threads"/"fork"/"cores"/"cpu").

Sachant qu'un serveur de base dispose de 256Go RAM et 28 CPU/Cores, c'est le maximum que l'on peut allouer pour un job.
Je n'ai pas d'expérience sur le logiciel pour savoir le bon nombre de threads à utiliser. Il faut tester. A priori, plus on utilise de threads, plus ce sera rapide. Essayons avec 12 threads.
Il faudra donc lancer qiime dada2 denoise-single avec l'option --p-n-threads 12.
Mais aussi demander à slurm de réserver 12 cores/CPU pour ce traitement: --ntasks-per-node=12
Il est très important de faire correspondre le nombre de threads du logiciel avec celui indiqué à Slurm (il y a sinon aucun gain).

Ainsi, on aura un script comme ci-dessous.
J'en profite pour indiquer plus d'option à Slurm: le nom du job, le temps d'éxécution (prendre bcp de marge), le nombre de serveur, le nom de la partition ("fast" si job < 24h), le fichier de sortie (je peux indiquer un non ou un path différent) et demander à recevoir des courriels.
Vient ensuite quelques infos utiles à renvoyer, le chargement des modules et finalement notre commande !
Le script est devenu plus touffu masi ce n'est qu'un exemple que je vous laisse adapter à vos besoins.

#!/bin/bash

################################ Slurm options #################################

### Job name (default: name of the script)
#SBATCH --job-name=denoise

### Max run time "hours:minutes:seconds" (default: 1 hour)
#SBATCH --time=20:00:00

### Requirements nodes/servers (default: 1)
#SBATCH --nodes=1

### Requirements cpu/core/task (default: 1)
#SBATCH --ntasks-per-node=12

### Requirements memory (default: 2GB per cpu)
#SBATCH --mem-per-cpu=8GB

### Partition (default: fast)
### fast = job time < 24h
### long = job time < 10j
#SBATCH --partition=fast

### Sortie (default: slurm-[jobid].out)
#SBATCH --output=slurm-%j.out

### Send mail on events (NONE, BEGIN, END, FAIL, ALL)
#SBATCH --mail-user=email@address
#SBATCH --mail-type=ALL

################################################################################


# Useful information to print
echo '########################################'
echo 'Date:' $(date --iso-8601=seconds)
echo 'User:' $USER
echo 'Host:' $HOSTNAME
echo 'Job Name:' $SLURM_JOB_NAME
echo 'Job Id:' $SLURM_JOB_ID
echo 'Directory:' $(pwd)
echo '########################################'

# modules loading
module load qiime2/r2019.01

# QIIME2 dada2 denoise
qiime dada2 denoise-single --p-n-threads 12 --i-demultiplexed-seqs seq_single_end_16S.qza --p-trunc-len 0 --output-dir dada2_denoise --verbose


echo '########################################'
echo 'Job finished' $(date --iso-8601=seconds)

N'hésitez-pas à nous faire une retour ou à revenir vers nous si cela ne fonctionnait pas.

Bonne journée et bon calcul :slight_smile:

2 « J'aime »
3

En complément de l'excellente réponse de @dbenaben, je voulais préciser les options à utiliser pour srun/sbatch.

Si qiime peut tirer parti de multiple threads, dans ce cas l'option à utiliser dans slurm est --cpus-per-task.
Slur le cluster de l'IFB, une task est un processus, un CPU correspond à un coeur et chaque coeur dispose de 2 threads. Ainsi pour réserver 12 threads, il faut utiliser l'option --cpu-per-tasks=6.

Vous pouvez par exemple lancer la commande suivante :

srun --cpu-per-tasks=6 --mem=16GB qiime dada2 denoise-single --i-demultiplexed-seqs seq_single_end_16S.qza --p-trunc-len 0 --output-dir dada2_denoise --verbose --p-n-threads 12

Attention, n'utilisez jamais l'option --p-n-threads 0 pour ne pas risquer d'utiliser des threads que vous n'auriez pas explicitement réservés sur le noeud qui vous est alloué.
De plus, en utilisant l'option --mem-per-cpu=16GB vous réservé 16GB de RAM par thread. A voir si c'est bien ce dont vous avez besoin. L'option --mem=16GB réserve 16GB pour l'ensemble de la task.

4

Bonjour à tous les 2 !

Merci pour vos réponses multiples que j'ai mis un peu de temps à tester, désolé.
J'ai d'abord essayé simplement la ligne de commande proposé par Julien (en corrigeant cpus-per-task :wink:) et le résultat a été encourageant avec une avancée plus importante de l'analyse mais toujours avec un arrêt inopiné après 1h30-1h45 sans info particulière. Je ne comprends donc pas le problème !
Par contre suite à ça j'ai testé le script bash et le lancement en batch de ma commande et là miracle (merci David @dbenaben !! :slight_smile: ) après plus de 8h de calcul l'analyse est terminée !
Je vais creuser pour vérifier que tout c'est bien passé mais je pense que c'est ok.
Je ne sais pas si vous avez une explication mais toujours est-il que mon problème semble résolu.
Merci beaucoup à vous deux ! :grinning::ok_hand:
Mathias