Jobs multicore dans WLCG Présentation en partie basée sur des présentations faites dans le cadre du groupe de travail multicore.

Thèmes abordés C’est quoi un job multicore dans le cadre LCG. L’ordonnancement des jobs multicore dans nos systèmes de batch. – C’est un sujet qui est plutôt derrière nous mais qui par nature reviendra sur le devant de la scène notamment pour des raisons d’optimisation. Le contrôle de l’utilisation des ressources consommées par des jobs. – C’est le sujet d’actualité Les questionnements qui sont d’actualités avec les jobs multicore dans nos systèmes.

Jobs multicore Ce n’est pas un job parallèle qui utilise une librairie de communication de type MPI, ni même un job fortement multithreadé (librairie openmp) Le périmètre de ressources utilisables est donc au maximum le serveur (node) –  Nos clusters sont rarement constitués de serveurs techniquement identiques Pour instant au niveau des applications, l’intérêt des jobs multicore n’est pas dans l’utilisation de la puissance cpu des cores qui sont mis en jeu dans un job MC.

Jobs multicore Pour instant au niveau des applications, l’intérêt des jobs multicore n’est pas dans l’optimisation des I/O sur le serveur. A ce jour la principale raison d’être des jobs MC est d’aller au delà de la limitation de 2Go de mémoire /jobs et de limiter les multiples instanciations des mêmes données en mémoire

Ordonnancement de jobs MC C’est un problème de site – On veut maximiser l’utilisation de nos ressources. C’est un problème d’autant plus difficile à aborder que le bestiaire des types de jobs est grand – multicore vs monocore vs MPI – Application A vs Application B vs Application xxx – Job pur CPU vs Job I/O intensif – Job courts vs job longs Plus ou moins ( jusqu’à l’impossibilité ) facile à aborder en fonction des capacités/fonctionnalités du batch système/ordonnanceur

Ordonnancement de jobs MC Deux approches possibles dans notre contexte: Dédier une ressource aux jobs multicore – Facile a mettre en œuvre, mais une efficacité d’utilisation des ressources rarement optimale Affecter dynamiquement les ressources multicore en fonction du besoin – La bonne approche mais un peu plus difficile à mettre en œuvre

Ordonnancement de jobs MC Les points à prendre en compte sont: – Allouer une ressource complexe (MC) coûte cher en terme de disponibilité. Il vaut mieux ne pas le faire pour rien – Libérer une ressource complexe (MC) trop vite peut être particulièrement inefficace si on en a de nouveau besoin peu de temps après. – N’avoir que des ressources complexes (MC), c’est ordonnancer sur une population de ressources faible et donc ou les effets statistiques sont moins probant. Les batch système/ordonnanceur mettent en œuvre des mécanismes pour tenter d’aborder ces points (backfilling, réservation dynamique et temporelle, profondeur de réservation,…)

Ordonnancement de jobs MC Tous ces mécanismes sont efficaces si on connait à l’avance les caractéristiques des jobs à exécuter – Soit de façon statistique. – Soit parce que les jobs annoncent leurs caractéristiques à l’avance. A ce jour les jobs LCG ne répondent pas de façon satisfaisante à ces deux conditions. Aujourd’hui un grand nombre de sites ont mis en place des queues multicore. – Au niveau des sites il existe un intérêt a « monitorer » le bon usage des ressources dans ce contexte

Monitoring de l’usage des job slot pour ATLAS

Ressources consommées dans un job (MC) Deux sujets sont traités en ce moment par la TF Multicore de WLCG – Faire en sorte que les jobs passent des informations concernant leur caractéristiques aux systèmes de batch. On vient de voir l’intérêt de la chose – Gestion des limites de consommation des ressources par un job ( notamment la mémoire) Problématique qui est devenue importante avec l’arrivée des jobs multicore

Ressources consommées dans un job (MC) Informations transmises au batch système – CPUTIME – WALLTIME – NB de core – MEM – VMEM Cela pose la question des informations qui sont publiées dans le système d’information – Peut on passer outre ? – Doit on plutôt définir des valeurs Min et Max – On suit quel schéma GLUE1 GLUE2 ?

Ressources consommées dans un job (MC) La gestion de la mémoire est la principale raison des jobs multicore. Par définition les jobs multicore partagent de la mémoire Comptabiliser la consommation mémoire ( laquelle la virtuelle la RSS) devient plus complexe – Des outils standards peuvent donner des valeurs différentes Un non contrôle de la consommation mémoire et très souvent fatal au serveur (perte de ressource) Les applications WLCG ont tendance à accroitre leurs besoins de mémoire

Ressources consommées dans un job (MC) Les pistes pour aborder ce point sont : L’utilisation des cgroups qui permettent pour une process particulier de contrôler par des limites HARD ou SOFT les consommations mémoire – Nécessite d’être pris en charge au niveau du batch système. Interagir avec les maps (proc/$PID/maps) des process – Il n’y pas vraiment de mécanisme standard pour interagir avec ces éléments.

Interrogation Allons nous aussi les aborder les jobs multicore sous les aspects – Jobs multithreadés (notamment avec la version multithread de geant) ? – I/O.Des jobs multithreadés ne vont ils pas amener des congestions sur les I/O ? Dans ce cas allons nous aussi aller vers la gestion des I/O dans nos batch systèmes ? Allons nous aussi aller vers des jobs parallèles (MPI), qui sont une problématique toute autre Un site qui propose une service commun doit faire en sorte de ne pas défavoriser un « client » au profil d’un autre