Problème mémoire Picard MarkDuplicates

IFB Core Cluster
1

Bonjour,

J'utilise le programme Picard MarkDuplicates sur des fichiers .bam dont la taille est comprise entre 19 GB et 32 GB. Après avoir échoué au niveau de mon pipeline snakemake, j'ai tenté d'utiliser ce programme directement dans un script réclamant 128GB de RAM et lancé en sbatch. Voici l'entête du script :

#!/bin/bash
###################configuration slurm##############################
#SBATCH -A invalbo
#SBATCH --job-name=markdup
#SBATCH --time=6-23:00:00
#SBATCH -p long
#SBATCH -N 1
#SBATCH -n 1
#SBATCH --cpus-per-task 26
#SBATCH --mem=128GB
#SBATCH -o Cluster_logs/%x-%j-%N.out
#SBATCH -e Cluster_logs/%x-%j-%N.err
#SBATCH --mail-user=loic.talignani@ird.fr
#SBATCH --mail-type=ALL
###################################################################

Je ne suis d'ailleurs pas sûr de pouvoir réclamer autant de mémoire sur la partition long et que les 128 GB soient bien alloués. Je sais également que les 26 cpus réclamés sont inutiles. Tout conseil est le bienvenu.

Et voici la commande utilisée :

module load picard/2.23.5

picard MarkDuplicates -CREATE_INDEX TRUE -VALIDATION_STRINGENCY SILENT -I results/02_Mapping/Sample_8_EKDN230051730-1A_H2F5FDSXC_L1_bwa_sorted.bam -O results/02_Mapping/Sample_8_EKDN230051730-1A_H2F5FDSXC_L1_bwa_sorted-mark-dup.bam -M results/02_Mapping/Sample_8_EKDN230051730-1A_H2F5FDSXC_L1_bwa_sorted-mark-dup_metrics.txt > results/11_Reports/markduplicatesspark/Sample_8_EKDN230051730-1A_H2F5FDSXC_L1_bwa_sorted-mark-dup.log 2>&1

Dans les logs, la première ligne indique :

Start of doWork freeMemory: 530666392; totalMemory: 536870912; maxMemory: 2147483648

J'ai l'impression de ne pas avoir 128GB mais bien les 2GB du cpu.

Puis j'ai l'erreur suivante :

[Wed Feb 21 17:36:18 UTC 2024] picard.sam.markduplicates.MarkDuplicates done. Elapsed time: 11.26 minutes.
Runtime.totalMemory()=2147483648
To get help, see http://broadinstitute.github.io/picard/index.html#GettingHelp
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.HashMap.resize(HashMap.java:699)
	at java.base/java.util.HashMap.putVal(HashMap.java:658)
	at java.base/java.util.HashMap.put(HashMap.java:607)
	at htsjdk.samtools.CoordinateSortedPairInfoMap.ensureSequenceLoaded(CoordinateSortedPairInfoMap.java:134)
	at htsjdk.samtools.CoordinateSortedPairInfoMap.remove(CoordinateSortedPairInfoMap.java:86)
	at picard.sam.markduplicates.util.DiskBasedReadEndsForMarkDuplicatesMap.remove(DiskBasedReadEndsForMarkDuplicatesMap.java:61)
	at picard.sam.markduplicates.MarkDuplicates.buildSortedReadEndLists(MarkDuplicates.java:559)
	at picard.sam.markduplicates.MarkDuplicates.doWork(MarkDuplicates.java:257)
	at picard.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:301)
	at picard.cmdline.PicardCommandLine.instanceMain(PicardCommandLine.java:103)
	at picard.cmdline.PicardCommandLine.main(PicardCommandLine.java:113)

Quelles solutions préconisez-vous ? Passer sur Bigmem ?

Merci d'avance pour l'aide apportée.

Cordialement,

EDIT : j'ai ajouté l'option -Xmx32g à la commande picard. J'ai vu immédiatement que cela avait été pris en compte dans les logs :

Start of doWork freeMemory: 51057496; totalMemory: 58720256; maxMemory: 34359738368

Le job est toujours en cours.

2

Bonjour Loïc,

L'erreur renvoyée est assez courante avec Java.
Ce n'est pas la mémoire qui manque mais, pour simplifier, la mémoire alloué à Java (qui par défaut est assez faible, ~2Go max).
Il faut donc augmenter la mémoire utilisée par la machine virtuelle Java (JVM).
Plus d'info ici: java - What are the -Xms and -Xmx parameters when starting JVM? - Stack Overflow

Par exemple, en ajoutant l'option -Xmx8g lorsque vous lancer java.
Certains outils comme picard, snpEff, etc utilisent java sans que ce soit visible.
Il faut alors arriver à spécifier cette option au lancement (exemple sur le forum: Problème Java heap space - #2 par dbenaben, Problème picard tools - #2 par Mag, Error Pilon (polishing) - #2 par dbenaben)
En bref:

# Pour donner 8G de RAM à la JVM
picard -Xmx8g MarkDuplicates -I bam ... 
# Cela équivaut à lancer
java -Xmx8g -jar picard.jar MarkDuplicates ...

Si on regarde vos jobs, la mémoire semble bien utilisé. Par exemple pour votre dernier job via la commande seff on observe que le job est monté à 100Go (et a utilisé 50% des CPU):

$ seff 37935272
Job ID: 37935272
Cluster: core
User/Group: ltalignani/ltalignani
State: COMPLETED (exit code 0)
Nodes: 1
Cores per node: 2
CPU Utilized: 02:38:07
CPU Efficiency: 51.33% of 05:08:04 core-walltime
Job Wall-clock time: 02:34:02
Memory Utilized: 100.81 GB
Memory Efficiency: 78.76% of 128.00 GB

Une fois le job terminé, vous pouvez vérifier l'usage des ressources avec sacct ou seff (et c'est une bonne pratique de le faire:
Voir Job information on ended job ou https://ifb-elixirfr.gitlab.io/cluster/doc/troubleshooting/#slurm-how-to-use-resources-wisely

Pour info si 128G n'est pas suffisant, vous pouvez aujourd'hui monter jusqu'à 1500G sur les noeuds standards (de nouveau serveurs ont été mis en service).