Bonjour à toutes et à tous,
J'utilise occasionnellement le cluster pour faire le mapping d'un transcriptome.
J'ai un soucis avec SortMeRNA:
J'ai un workflow snakemake qui fonctionne avec des échantillons paired-end contenant environ 25 millions de reads mais il bloque pour, je pense, un problème d'allocation de mémoire pour la règle SortMeRNA avec des échantillons paired-end d'environ 50 millions de reads. La version de SortMeRNA que j'utilise est 4.3.6.
L'arrêt se fait toujours après le splitting des fichiers, l'alignement ne démarre jamais.
Serait-il possible de m'aider à bien allouer la mémoire, j'ai déjà testé différentes possibilités mais il y a toujours un arrêt avant l'alignement.
Message: Segmentation fault (core dumped)
Voici un exemple de ressources que j'ai mises:
config (snakemake):
sortmerna:
runtime: 240
cpus_per_task: 8
nodes: 1
tasks: 1
mem_mb: 32000
Lorsque je consulte les issues de SortMeRNA Issues · sortmerna/sortmerna · GitHub, je vois qu'il semble que ce soit un problème rencontré par d'autres mais je n'ai pas de solution.
Je vous remercie par avance.
Cordialement,
Dominique
Il faudrait partager votre script snakemake (et la commande que vous lancez sur le cluster) pour voir comment vous allouez la mémoire dans les règles. Merci!
Bonjour,
Merci pour votre réponse.
Voici des extraits de mes scripts et les commandes:
config.yaml:
executor: "slurm"
default-resources:
slurm_account: "account"
slurm_partition: "fast"
runtime: 120
cpus_per_task: 1
nodes: 1
tasks: 1
mem_mb: 2000
jobs: 100
set-resources:
sortmerna:
runtime: 240
cpus_per_task: 8
mem_mb: 32000
snakefile:
SAMPLES, = glob_wildcards(config["dataDir"]+"{sample}_R1.fastq.gz")
R = ["R1","R2"]
rule all:
input:
expand("sortrna/{sample}/out/other_fwd.fq.gz",sample=SAMPLES),
expand("sortrna/{sample}/out/other_rev.fq.gz",sample=SAMPLES)
rule sortmerna:
output:
R1= "sortrna/{sample}/out/other_fwd.fq.gz",
R2= "sortrna/{sample}/out/other_rev.fq.gz"
input:
R1 = "Cutadapt/{sample}_R1-cutadapt.fastq.gz",
R2 = "Cutadapt/{sample}_R2-cutadapt.fastq.gz"
params:
rna = config["dataDir"]+config["rna"],
sortdir = lambda wildcards, output: output[0][:-20]
threads: 8
log:
log1="Logs/{sample}_sortmerna.log1",
log2="Logs/{sample}_sortmerna.log2"
shell: "sortmerna --ref {params.rna} \
--reads {input.R1} --reads {input.R2} \
--workdir {params.sortdir} \
--num_alignments 1 --threads {threads} --fastx --other --paired_out --out2 \
1>>{log.log1} 2>>{log.log2}"
Commandes:
$module load snakemake/8.0.1 sortmerna/4.3.6
$snakemake --profile /shared/projects/account/profiles/default/ -s /shared/projects/account/snakefile.smk --configfile /shared/projects/account/config.yml
Merci.
Dominique
Bonjour,
Je tenais à vous faire un retour d'expérience de ce programme que j'utilise depuis trois ans maintenant, complété par les bases de données SILVA DB SSU et LSU.
Sur un autre cluster, j'ai également eu beaucoup de soucis de ce genre avec SortMeRNA. Il y a pas mal de personnes qui se plaignent de ce problème sur leur Github.
SortMeRNA commence par splitter le jeu de données en autant de fichiers que de cpus. 50 millions de reads commencent également à faire beaucoup.
De mon côté, j'utilise SortMeRNA pour filtrer des rRNAs en amont d'un pipeline de métagénomique virale sur des fastq compressés de 40-60 millions de reads. Je n'hésite plus à demander 40 cpus et 256GB rien que pour SortMeRNA et la commande seff me montre que les cpus et la RAM sont bien utilisés.
Il arrive tout de même que quelques fastq ne passent pas, mais dans ce cas, c'est plus un problème lié à un manque de spécificité des sondes de métabarcoding utilisées, qui amplifient l'hôte plutôt que les virus recherchés. Je teste donc les fastq avec Fatsq-screen au préalable afin de m'assurer que l'hôte n'a pas été amplifié (Aedes albopictus).
J'ai bien tenté d'utiliser d'autres programmes, mais ils ne sont pas aussi aboutis que SortMeRNA.
Voilà pour ce retour d'expérience, n'hésitez pas si vous avez d'autres questions.
1 « J'aime »
Bonjour,
Merci pour votre retour d'expérience.
Je vais tenter avec 40 cpus et 256GB.
Bien cordialement,
Dominique
Bonjour,
Même avec 40 cpus et 256GB, le processus s'arrête après le splitting (environ 1h) et ne démarre pas l'alignement. Toujours le même message d'erreur:
Segmentation fault (core dumped)
Dans le log slurm pour la rule sortmerna, je vois que les 40 cpus et les 256GB aient été pris en compte, est-ce que je dois changer la quantité de mémoire pour le disk?
resources: mem_mb=256000, mem_mib=244141, disk_mb=6562, disk_mib=6259, tmpdir=/tmp, slurm_account=e_muse_esr5, slurm_partition=fast, runtime=240, cpus_per_task=40, nodes=1, tasks=1
C'est au moment de la transition vers l'alignement qu'il y a un problème, je ne vois pas comment le résoudre.
Merci.
Bien cordialement,
Dominique
Ca ressemble à un problème d'allocation de ressources, comme une limitation de la quantité de fichiers contenus dans un répertoire, où de limite d'espace disque. Est-il possible d'avoir les logs complets de SortMeRNA (assez longs malheureusement).
Il faudrait peut-être voir avec un admin si une limite n'a pas été atteinte sur l'allocation d'espace disque. Je sais que sur un de mes pipelines Snakemake qui produit beaucoup de fichiers, j'ai forcé l'écriture de tous les fichiers dans le répertoire d'analyse avec la commande
export XDG_CACHE_HOME=/shared/projects/<your_directory>/
mais c'est peut-être hors sujet.
Quels sont les résultats obtenus avec FastQC ? Et testez-les éventuellement avec Fastq-screen.
Sinon, pour le debug, hors snakemake, faire tourner la commande SortMeRNA avec srun et voir ce que ça donne.
Merci pour votre retour.
J'ai fait précédemment un srun et c'est toujours avant de démarrer l'alignement que ça s'arrête.
Je mets juste la fin d'un essai:
[split:605] start splitting. Using number of splits equals number of processing threads: 24
[next:322] EOF FWD reached. Total reads: 58536532
[next:322] EOF REV reached. Total reads: 58536532
[split:717] Done splitting. Reads count: 117073064 Runtime sec: 3989.93
[init:135] Readfeed init done in sec [4396.09]
[store_to_db:292] Stored Reads statistics to DB:
all_reads_count= 117073064 all_reads_len= 8279929441 min_read_len= 33 max_read_len= 75 total_aligned= 0 total_aligned_id= 0 total_aligned_cov= 0 total_aligned_id_cov= 0 total_densrun: error: cpu-node-31: task 0: Segmentation fault (core dumped)
Sur le github sortmerna (Segmentation Faults while processing options · Issue #422 · sortmerna/sortmerna · GitHub)
Je vois qu'ils obtiennent le message d'erreur suivant:
[init:135] Readfeed init done in sec [522.293]
[store_to_db:292] Stored Reads statistics to DB:
all_reads_count= 14683903 all_reads_len= 2191830758 min_read_len= 36 max_read_len= 151 total_aligned= 0 total_aligned_id= 0 total_aligned_cov= 0 total_aligned_id_cov= 0 total_denovo= 0 num_short= 0 reads_matched_per_db= TODO is_stats_calc= 0 is_total_reads_mapped_cov= 0
[align:143] ==== Starting alignment ====
[align:146] Number of cores: 8
[align:163] Using number of Processor threads: 4
malloc(): invalid next->prev_inuse (unsorted)
Aborted (core dumped)
En ce qui me concerne, l'alignement ne démarre jamais.
En ce qui concerne les fastqc, je n'ai pas de soucis d'analyse.
Bonjour,
Je viens de jeter un oeil sur les ressources.
- A première vue, ce n'est pas un problème de quota (vous n'avez atteint aucune limite)
- A première vue, ce n'est pas un problème de ressources allouées (CPU ou RAM).
Les jobs ne sont pas tués à cause de la mémoire ou autre.
L'erreur Segmentation fault me semble d'ailleurs pointer plutôt une erreur dans le code ou dans les données.
Suite à vos discussions, je me demande si ce n'est pas une limite système sur le "nombre maximum de fichier ouvert".
On regarde et je reviens vers vous.
OK.
Dans certains cas, il m'avait été conseillé de réduire le nombre de cpus mais vous n'en utilisez que 8 et vous avez eu le même problème. Parfois, je comprends que cela puisse être contreproductif car le split des données est plus long et le programme peut se perdre en route.
Je sais également que l'option --other pose problème dans certains cas.
Voir ici : https://github.com/sortmerna/sortmerna/issues/288
A voir si vous avez besoin de cette option et si vous l'utilisez. Moi oui, car mon analyse s'effectue justement sur le fichier généré par la commande --other.
Merci pour vos réponses.
Dominique
Bonjour,
J'ai également besoin de l'option --other pour la suite de mon analyse.
Dominique
Bonjour,
J'ai testé 1 cpu, pour diminuer le nombre de fichier et même problème. Alors que le même script (1 cpu) avec des fichiers contenant environ 2x moins de reads ne bloque pas.
J'ai fait un sbatch avec
#SBATCH --cpus-per-task=56
#SBATCH --mem-per-cpu=4G
Et cette fois l'alignement a démarré mais s'est arrêté en cours et toujours le même message d'erreur:
srun: error: cpu-node-90: task 0: Segmentation fault (core dumped)
Si vous avez une idée, merci.
Dominique
Bonjour @Dominique
Pourriez-vous faire un essai en rajoutant les options ci-dessous ?
#SBATCH -N 1
#SBATCH -w cpu-node-[30-70]
Et en diminuant la demande de ressource CPU/RAM (~ --cpus-per-task=26)
J'essaye.
Merci
Dominique
j'ai ce message d'erreur:
sbatch: error: invalid number of nodes (-N 41-1)
sbatch: Warning: can't run 1 processes on 41 nodes, setting nnodes to 1
ok. Tant pis.
On essai de déployer la modification sur la limite du 'nombre de fichier ouvert" rapidement