Bonjour,
J'utilise depuis récemment le cluster de l'ifb, j'utilise un programme nextflow que j'ai conçu pour faire mes calculs, mais mes jobs sont tués à interval régulier avec l'erreur:
The thread pool executor cannot run the task. The upper limit of the thread pool size has probably been reached. Current pool size: 1000 Maximum pool size: 1000.
J'ai pourtant limité avec nextflow le nombre de jobs actifs en même temps à 300.
Pourriez vous m'expliquer ce qui génère cette erreur ?
Merci,
Bonjour Amine,
Content de te croiser sur le cluster de l'IFB 
Les nœuds standard les plus courants sur le cluster ont 2 Intel Xeon E5-2695v3 (chacun de 14 cœurs). Ce qui nous fait 28 cœurs et 56 cœurs en comptant l'hyperthreading.
Basiquement, il est rarement approprié d'avoir un nombre de thread supérieur aux nombre de cœurs (dans notre cas, je ne dépasserais pas 56 par serveur).
Je suis donc surpris du "thread pool size" qui me semble bien trop élevé et pourrait, je pense, causer ce type d'erreur.
Le nombre de job peut être différent du nombre de thread (1 job peut utliliser plusieurs threads).
Il me semble donc important de limiter le nombre de jobs mais aussi le nombre de threads.
Est-il possible d'avoir plus d'information (version de nextflow utilisé, config nextflow, script nextflow, étape/programme du script qui génère l'erreur, log) ? Je ne connais pas bien nextflow et cela me permettrais de mieux comprendre le problème.
Bonjour David,
j'apprends également que tu maintiens le cluster de l'ifb
J'utilise la dernière version en date de nextflow 20.01.0.5264, plus avancée qui est disponible sur module qui doit être une 18.10. J'avais des soucis avec les historiques sur cette version qui ont disparus en passant à la dernière version.
Le programme est disponible ici: GitHub - aghozlane/pcm: A 3D-based method to annotate resistance genes , c'est la branche dev que j'execute en ce moment
et la config est la suivante:
process {
withName: search_distant_homologuous {
memory = '10 GB'
}
withName: index_query {
memory = '30 GB'
}
}
profiles {
singularity {
process.container = 'file:///shared/home/aghozlane/pcm/pcm_202002.img'
singularity.enabled = true
process.executor = 'slurm'
singularity.autoMounts = false
singularity.runOptions = "-B /shared:/shared"
process.clusterOptions='--qos=fast'
process.queue = 'fast'
process.memory = '4 GB'
timeline.enabled = true
report.enabled = true
process.maxForks = 300
}
}
Au moment du crash fait plusieurs étapes en différentes:
La zone où crash nextflow est assez aléatoire, je pense que c'est le process principal qui n'arrive plus à soumettre de job.
Je vais soumettre cette question aux développeurs de nextflow, je pense qu'il y a une subtilité qui m'échappe.
Merci pour les infos complètes
J'arrive à reproduire l'erreur systématiquement avec maxForks > 1000.
Je pense également que l'erreur vient du process principal.
J'observe que lors du lancement de nextflow, un thread est créé par le process principal pour chaque job à lancer par nextflow. Au delà de 1000 threads, ça plante avec l'erreur "The upper limit of the thread pool size has probably been reached".
Je ne pense pas que ce soit dû au système mais penche plutôt pour une limite de java ou nextflow.
Je continue à fouiller.
Bonne soirée
Le développeur principal de nextflow m'a répondu de me tourner vers la version en cours de développement qui règle ce soucis. Je pense que nextflow ne libérait pas correctement les threads des jobs terminés. Ca a l'air de tourner pour l'instant, j'ai passé les 1300 jobs soumis.
Merci en tout cas.
Bonjour Amine,
Je pense que c'est lié au traitement des threads sous java (ThreadPoolExecutor, maximumPoolSize).
N'hésites pas à nous faire part du retour des développeurs de nextflow.
On reste disponible pour en discuter si besoin.
Nos messages se sont croisés.
Merci pour l'info
