Meilleure manière de lancer de nombreux jobs

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).

Bonjour Arnaud,

Désolé pour ce retour tardif.

En effet, le job array me semble aussi une bonne solution.
De manière général, je pense qu'il vaut mieux avoir plein de "petits" jobs (en terme de CPU, RAM et walltime) que de "gros" jobs.

Mais il est vrai que les seuils de soumission actuels sont trop limitants.
Nous allons les augmenter et revenons vers vous dès que c'est fait.

Bonne fin de journée

1 J'aime

Bonjour Arnaud,

La configuration du Cluster a été mis à jour ce WE (merci @julien et @haessigj).

La limitation à 500 jobs soumis a été supprimée et les autres contraintes réhaussées (x10):
MaxJobCount=100001
MaxArraySize=10001

Cela devrait permettre de lancer les jobs souhaités plus simplement (en array par exemple).

Bonne journée

1 J'aime

Bonjour,

Merci beaucoup! Je vais essayer ça pour mon prochain (et dernier) run.

Arnaud

Après avoir essayé : ça marche très bien. Merci beaucoup, c'est beaucoup plus pratique comme ça.

Arnaud

2 J'aime

Bonjour,
Il semble que la limite MaxArraySize soit repassée à 1001.
Serait-il possible de refaire un x10 ?

Merci !

Ping @team.ifbcorecluster

1 J'aime

Merge Request en cours

1 J'aime