Bonjour,
Cela fait plusieurs jobs qui se terminent en erreur oom-kill (job id : 23214867, 23178091, 23175866).
Serait-il possible d'avoir accès à la partition big mem pour le projet mothard_in_silico_modeling ?
Cordialement,
Céline
Bonjour,
Cela fait plusieurs jobs qui se terminent en erreur oom-kill (job id : 23214867, 23178091, 23175866).
Serait-il possible d'avoir accès à la partition big mem pour le projet mothard_in_silico_modeling ?
Cordialement,
Céline
Bonjour Céline,
C'est fait. Pensez à demander explicitement la partition lors de la soumission de job (--partition bigmem
).
Bonne après-midi
Merci beaucoup David !
Bonjour
j'ai un script R qui pose problème et je suspecte que c'est lié à la mémoire: pourrais je avoir temporairement accès à la partition bigmem?
merci
Didier
Bonjour,
Je ne pense pas que la mémoire soit limitante dans votre cas.
Vous pouvez vérifier l'usage: SLURM job efficiency - IFB Core Cluster Documentation (de manière générale, c'est important de vérifier le bon usage des ressources)
Par exemple pour le job 43544157
, seul 1.6% de la mémoire demandée a été utilisé.
$ module load reportseff
$ reportseff 43544157
JobID State Elapsed TimeEff CPUEff MemEff
43544157 COMPLETED 00:03:08 1.3% 8.0% 1.6%
Plus précisément, 16Go (MaxRSS) / 1To (ReqMem):
sacct -o JobID%15,JobName%10,Partition,ReqMem,MaxRSS%15,AllocCPUS,Timelimit,Elapsed,State%20 -j 43544157
JobID JobName Partition ReqMem MaxRSS AllocCPUS Timelimit Elapsed State
--------------- ---------- ---------- ---------- --------------- ---------- ---------- ---------- --------------------
43544157 RAD_dista+ fast 1T 12 04:00:00 00:03:08 COMPLETED
43544157.batch batch 16839400K 12 00:03:08 COMPLETED
Y'a-t-il une erreur qui vous fait pointer la mémoire ?
Je vous ai quand même donné l'accès à bigmem
pour le projet gfcm_redcoral2024_up
si besoin.
Dans tous les cas, pensez-à bien vérifier l'usage des ressources !
Merci pour l'accès à la partition: j'ai vu qu'on doit explicitement la partition lors de la soumission de job (--partition bigmem
). Mais est-ce qu'on précise quand même la mémoire demandée dans le script? apparemment si je le fais, j'ai une erreur:
sbatch: error: Batch job submission failed: Requested node configuration is not available
si je ne spécifie pas la mémoire, le script se lance mais j'ai une erreur:
/var/spool/slurm/slurmd/job43567127/slurm_script: line 41: 3667249 Killed Rscript tri_duplicats_distances_poppr_red_coral_GFCM_cluster_IFB.R
########################################
Job pairwise_RAD_distances finished 2025-01-22T14:40:50+01:00
slurmstepd-cpu-node-5: error: Detected 1 oom_kill event in StepId=43567127.batch. Some of the step tasks have been OOM Killed.
si je vérifie l'usage (merci!) j'ai ceci:
(base) daurelle@clust-slurm-client2:~$ reportseff 43567127
JobID State Elapsed TimeEff CPUEff MemEff
43567127 OUT_OF_MEMORY 00:04:19 1.8% 97.3% 34.3%
Je précise que cette analyse vise à calculer une grande matrice de distances par paires.
Didier
Oui, il faut absolument spécifier a quantité de mémoire souhaité, la partition et le projet (en plus des cpu, time, etc).
A défaut, vous vous retrouver avec la quantité par défaut ("2Go") et votre script plante par manque de mémoire.
A savoir
#SBATCH -p bigmem
#SBATCH -A gfcm_redcoral2024_up
#SBATCH --mem XTB
# [...]
Mais encore une fois, je doute sérieusement que la mémoire soit en cause.
Peut-être tester sur un tout petit jeu de donnée ? Ou un jeu de test connu ?
Oui, j'ai testé sur un petit jeu de données en local et sur le cluster et j'arrive à avoir la matrice de distances.
Par contre ça bloque toujours sur bigmem:
dans le script je spécifie
#SBATCH -p bigmem
#SBATCH -A gfcm_redcoral2024_up
#SBATCH --mem 4TB
je lance:
sbatch IFB_analyses_red_coral_duplicates_2024.sh --partition bigmem
et j'ai l'erreur:
sbatch: error: Memory specification can not be satisfied
sbatch: error: Batch job submission failed: Requested node configuration is not available
Le maximum possible est 3To: Cluster description - IFB Core Cluster Documentation
Mais essayez déjà avec 2To.
Note: il faudra peut-être préciser aussi la qos:
#SBATCH --qos bigmem
Bonjour
effectivement j'avais mal lu la documentation sur le maximum possible
J'ai lancé avec 2 TB et le job reste pending (Resources)
Avec 1 TB le job se lance sur cette queue mais mon script donne l'erreur suivante:
*** caught segfault ***
address 0x1515cd0b3990, cause 'memory not mapped'
Traceback:
1: vapply(x, function(x) .Call("pairdiffs", x@tab)/2, numeric(np))
2: diss.dist(x = RADind, percent = TRUE, mat = TRUE)
An irrecoverable exception occurred. R is aborting now ...
/var/spool/slurm/slurmd/job43646087/slurm_script: line 47: 1628335 Segmentation fault Rscript tri_duplicats_distances_poppr_red_coral_GFCM_cluster_IFB.R
L'erreur se produit pour la fonction diss.dist du package R poppr.
merci
Didier
Bonjour,
C'est une segfault
.
L'erreur peut être assez difficile à déterminer: erreur dans le code, problème dans les données d'entrées, etc.
Mais ce n'est pas lié à la quantité de mémoire (a noter que votre programme à utiliser 2.4Go sur 1To disponible).
Bonsoir
merci pour le retour. J'ai trouvé une autre solution (en utilisant VCF2Dis GitHub - BGI-shenzhen/VCF2Dis: VCF2Dis: A new simple and efficient software to calculate p-distance matrix and construct population phylogeny based Variant Call Format). Je n'ai plus besoin de la partition bigmem
merci
Didier