Bonjour,
Quelle est la meilleure manière de lancer successivement de nombreux jobs, sans pourrir le cluster? (il s'agit de réplicats de simulations numériques, donc totalement indépendants les uns des autres). Peut-être un lien avec Lancer de nombreux jobs (plus de 1000) .
Mon workflow sur un serveur "traditionnel" repose sur GNU parallel,
parallel -j 64 -a myjobs.sh
va lancer une par une toutes les commandes de myjob.sh sans jamais en avoir plus de 64 en même temps.
C'est possible sur le cluster, c'est d'ailleurs comme ça que j'ai fait jusqu'ici, sauf que parallel ne dispatche pas les jobs sur des noeuds différents. Il faut donc saucissonner myjobs.sh en autant de tâches qu'il y a de noeuds:
parallel -j $SLURM_CPUS_PER_TASK -a myjobs1.sh &
parallel -j $SLURM_CPUS_PER_TASK -a myjobs2.sh &
Ça n'est pas très ergonomique, et ça empêche une tâche de démarrer s'il n'y a pas $SLURM_CPUS_PER_TASK cpu disponibles sur un noeud, ce qui n'est pas nécessaire (si on demande 52 cpu, il faut attendre que la totalité du serveur soit libre).
Une solution attirante, c'est d'utliser des arrays:
#SBATCH --array 1-1000%100
srun -n1 -N1 $(sed -n ${SLURM_ARRAY_TASK_ID}p myjobs.sh)
Mais ça coince à cause de la configuration de slurm (MaxJobs à 500, donc on ne peut pas lancer des arrays de plus de 500). Cette config empêche même de limiter les arrays à 500 et de lancer les sbatch en même temps (la limite est sur le total des jobs). On ne peut pas non plus utiliser --dependency pour lancer les batchs les uns à la suite des autres, pareil, MaxJobs limite le nombre de jobs soumis, et pas le nombre de jobs actifs.
Les arrays floodent aussi complètement le squeue, et génèrent des centaines de slurm*.out . Ce n'est peut-être donc pas la solution idéale. Quelle est la position des admins du cluster sur la meilleure solution? Du point de vue de l'utilisateur, il semble que le saucisonnage des batchs par noeud et l'utilisation de GNU parallel permet de maximiser les ressources tout en passant "sous les radars" au niveau du nombre de jobs lancés, mais au final, la charge sur le système reste la même et on perd beaucoup de souplesse (distribution rigide des tâches sur les noeuds).