Commande slurm indisponibles et problème avec la librairie joblib de python

Bonjour,

Il semblerait qu'il y ait un problème avec slurm en ce moment. Lorsque je tape des commandes simples comme squeue, sinfo, ou sbatch, j'obtiens comme erreur :
slurm_load_jobs error: Socket timed out on send/recv operation

Slurm fonctionnait très bien jusqu'à il y a une demi-heure environ mais j'avais des difficultés avec la librairie Joblib de python depuis ce matin pour faire tourner plusieurs jobs en parallèle (alors que cela fonctionnait très bien la semaine dernière) :

Erreur dans le fichier .out :


LokyProcess-1 failed with traceback:

Traceback (most recent call last):
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/externals/loky/backend/popen_loky_posix.py", line 176, in
process_obj = pickle.load(from_parent)
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/externals/loky/backend/synchronize.py", line 131, in setstate
self._semlock = _SemLock._rebuild(*state)
FileNotFoundError: [Errno 2] No such file or directory

Erreurs dans le fichier .err :

File "/shared/ifbstor1/projects/ecoli_dated_cluster_phylogenies/1_Effective_pop_sizes_and_selection/mutation_scores.py", line 621, in
Parallel(n_jobs=nthreads)( ###### ADDED
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/parallel.py", line 1950, in call
next(output)
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/parallel.py", line 1588, in _get_outputs
self._start(iterator, pre_dispatch)
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/parallel.py", line 1574, in _start
while self.dispatch_one_batch(iterator):
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/parallel.py", line 1462, in dispatch_one_batch
self._dispatch(tasks)
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/parallel.py", line 1384, in _dispatch
job = self._backend.apply_async(batch, callback=batch_tracker)
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/_parallel_backends.py", line 600, in apply_async
future = self._workers.submit(func)
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/externals/loky/reusable_executor.py", line 225, in submit
return super().submit(fn, *args, **kwargs)
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/externals/loky/process_executor.py", line 1226, in submit
raise self._flags.broken
joblib.externals.loky.process_executor.TerminatedWorkerError: A worker process managed by the executor was unexpectedly terminated. This could be caused by a segmentation fault while calling the function or by an excessive memory usage causing the Operating System to kill the worker.

The exit codes of the workers are {EXIT(1), EXIT(1)}
/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/externals/loky/backend/resource_tracker.py:314: UserWarning: resource_tracker: There appear to be 1 leaked file objects to clean up at shutdown
warnings.warn(

Auriez-vous une idée quant aux causes de ces problèmes ?

Merci beaucoup et bonne journée,
Manolo Mischler

Bonjour @Manolo

Désolé pour ce retour tardif. Nous avons eu en effet quelques souçis sur Slurm et avec le stockage pouvant causer ces erreurs.

Rencontrez-vous toujours des difficultés ?

Bonjour et merci pour votre réponse !

Je n'ai plus de soucis maintenant, j'ai pu utiliser slurm correctement depuis

Bonjour, je rencontre à nouveau la même erreur en voulant lancer un calcul avec la librairie Parallel de python dans un job :

LokyProcess-1 failed with traceback:

Traceback (most recent call last):
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/externals/loky/backend/popen_loky_posix.py", line 176, in < module >
process_obj = pickle.load(from_parent)
File "/shared/ifbstor1/software/miniconda/envs/python-pytorch-tensorflow-3.9-1.11.0-2.6.2/lib/python3.9/site-packages/joblib/externals/loky/backend/synchronize.py", line 131, in __ setstate __
self._semlock = _SemLock._rebuild(*state)
FileNotFoundError: [Errno 2] No such file or directory

Bonjour @Manolo,

Attention. Vous lancez votre job sur plusieurs serveurs de calcul (node=5). Sauf erreur de ma part joblib.Parallel ne travaille qu'avec des process ou des threads. Cela ne peut donc fonctionner que sur un seul serveur (node=1), mais bien-sûr avec plusieurs CPU.
L'erreur ne viendrait-elle pas de là ?

De manière générale avec de lancer un job et réserver autant de ressources, je vous invite à tester sur un petit jeux de données et à bien ajuster tous les paramètres. Et bien sûr à la fin de chaque job, à vérifier l'usage des ressources (https://ifb-elixirfr.gitlab.io/cluster/doc/slurm/slurm_user_guide/#job-information-on-ended-job), par exemple à l'aide la commande seff.

Merci pour votre réponse

Je vais effectivement prendre l'habitude d'utiliser la commande seff à l'issue de mes jobs pour vérifier que les ressources que j'ai demandées correspondent bien à ce qui est utilisé réellement !

J'ai déjà utilisé Parallel avec plusieurs nodes, mais quoiqu'il en soit cela fonctionne aujourd'hui en demandant un seul node de 25 cpus au lien de 5 nodes de 5 cpus

En règle général, à partir de quel nombre de cpus conseillez-vous d'utiliser plusieurs nodes au lien d'un seul avec plusieurs cpus ?

Bonjour,

En règle général, à partir de quel nombre de cpus conseillez-vous d'utiliser plusieurs nodes au lien d'un seul avec plusieurs cpus ?

Ce n'est pas une question de nombre de CPU.
On peut utiliser des milliers de CPU en lançant des milliers de jobs, chacun utilisant un CPU.
Par exemple: 1 traitement à faire sur 1000 données différentes --> 1 job par donnée --> 1000 jobs.
Ce type de parallélisation ("embarrassingly parallel") est le plus simple et le plus efficace.
C'est toujours ce que je recommande.

Pour utiliser plusieurs CPU au sein d'un job, il faut que le logiciel utilisé puisse le faire.
Le développeur a alors travaillé en ce sens et souvent utilisé des librairies permettant d'utiliser plusieurs cœurs de calcul (multiprocessing, OpenMP, etc.).
Le logiciel aura alors des options dédiées (<cpu>, <cores>, <threads>, <process>, <fork>, etc).
On pourra donc utiliser, au maximum, tous les CPU de la machine (même espace mémoire).

Mais pour utiliser tous les CPU sur plusieurs machines en utilisant un seul job, c'est une autre affaire !
A ce moment, le développeur s'appuie souvent sur la brique technique MPI. Mais cela demande du développement et assez peu de logiciels/librairies le proposent (d'autant que l'on peut souvent paralléliser par les données).

Il faut se référer à la documentation du logiciel ou de la librairie utilisée pour voir quelles options de parallélisations sont possibles.
Joblib, pour moi, ne supporte le calcul parallèle que sur une seule machine: Embarrassingly parallel for loops — joblib 1.5.dev0 documentation

En bref, il est rare que l'on utilise plusieurs serveurs avec un seul job.
On préférera lancer plusieurs jobs, chaque job utilisant un seul serveur mais potentiellement plusieurs CPU.

Merci pour votre réponse détaillée !

C'est justement mon cas, je lance le même programme sur 100 ou 200 données et pour l'instant je lançais un seul job et j'utilisais joblib.Parallel pour parallèliser sur les données au sein du job

Mais si je comprends bien votre réponse, vous conseillez plutôt de paralléliser au niveau du script bash lui-même, en lançant un job array par exemple ?

Oui tout à fait.
Soit un script lancé avec des options différentes (boucle for) ou encore mieux, comme vous le proposez, un "job array": SLURM advanced guide - IFB Core Cluster Documentation

Du coup, si vous devez faire le même traitement sur 100 ou 200 données, je lancerais 100 ou 200 jobs.
Quitte aussi à utiliser, au sein de chacun de ces jobs, plusieurs CPU (avec joblib.Parallel ou autre).

Merci c'est plus clair pour moi maintenant, je vais regarder la documentation !