Je suis en train de faire des tests pour tester les scripts que j’utiliserai en TP la semaine prochaine (merci encore à l’équipe pour les comptes étudiants temporaires !) et me familiariser avec le système. Mes jobs ont été interrompus assez rapidement pour un problème de mémoire :
[etoulza@clust-slurm-client ~]$ more slurm-36268.out
slurmstepd: error: Job 36268 exceeded memory limit (24822000 > 24576000), being killed
slurmstepd: error: *** JOB 36268 ON cpu-node-6 CANCELLED AT 2019-02-26T15:44:28 ***
slurmstepd: error: Exceeded job memory limit
Voici mon script :
#!/bin/bash #SBATCH --partition long #SBATCH --cpus-per-task 12
combien est-ce que je peux utiliser de cpus avec mes étudiants (vu que j’aurai 12 à 15 jobs en simultané selon les groupes pour un blastx de ~4000 séquences contre NR) ?
combien de mémoire je dois attribuer (–mem) pour être tranquille ?
[etoulza@clust-slurm-client ~]$ more slurm-36268.out
slurmstepd: error: Job 36268 exceeded memory limit (24822000 > 24576000), being killed
slurmstepd: error: *** JOB 36268 ON cpu-node-6 CANCELLED AT 2019-02-26T15:44:28 ***
slurmstepd: error: Exceeded job memory limit
C'est la grande question. C'est à évaluer par itération. Si on demandes "beaucoup trop", on peut potentiellement tu vas attendre plus longtemps pour obtenir les ressources (des admins regardant pourraient te le signaler). Et en effet, si pas assez, kill.
Mais blast n'est pas réputé pour consommé beaucoup de mémoire. Tente pour commencer :
Donc je dirais 4 et ça minimise le temps d'attente des jobs.
L'idéal avec Blast est de découper le fichier d'entrée et de soumettre autant de blast que de fichier d'entrée et de les soumettre via des job array mais c'est compliqué dans le cadre d'une formation.
JE confirme qu’il n’est pas nécessaire d’attribuer plus que 4 à 6 CPU par traitement et qu’il vaut mieux découper le fichier d’entrée.
En ce qui concerne la mémoire la mémoire je suis moins sur de moi . Je dirais que c’est peut être dépendant également de la taille de la banque de ref. (https://www.ncbi.nlm.nih.gov/books/NBK279695/#)
il y a manifestement qq parametres sur lesquels il est possible de jouer mais je n’ai pas d’experience sur le sujet .
dsl
Pour la mémoire, j’ai tendance à privilégier l’option --mem-per-cpu qui va permettre de faire varier la taille de la mémoire en fonction du nombre de CPU mais les deux sont bien évidemment valables.
Pour la quantité à réserver, pour moi, il faut tester. Quitte à demander une première fois trop de ressources, analyser ensuite les ressources utilisés et être plus restrictif sur les futurs jobs. La commande sacct peut alors être utile.
# sacct - displays accounting data for all jobs
sacct -l -j <jobid>
# ou en spécifiant les champs
sacct --format="JobName,NTasks,CPUTime,MaxRSS" -j <jobid>
Bonjour,
Je suis passée à 4 coeurs avec 20Gb de mémoire chaque pour que ça passe lors de mes tests (impossible en effet de découper les fichiers vu l’organisation des TP et le niveau débutant des étudiants). On va voir la semaine prochaine avec les étudiants si ça ne coince pas trop en termes de délai, je vous ferai un retour sur ce point.
Merci et bon week-end !
eve
@r1corre, @gildaslecorguille, est-ce que par hasard vous avez des examples de scripts SLURM pour lancer un BLAST en splittant les fichiers (type job-array) sur le cluster IFB ? un peu comme atomic_blast dans le temps
Sur une machine unique, j'utilise maintenant GNU parallel pour splitter les jobs BLAST, mais ça correspondrait à un job unique sur le cluster et j'ai des jobs qui vont dépasser le temps limite.
Merci d'avance
Pierre
