ATLAS Analysis Challenge Résultats du Stress Test Frédérique Chollet Information disponible sur le wiki LCG-France Minutes de la réunion T2-T3 du 19/12/08 CAF 13 Dec. 2009

2 « Stress tests » orienté Analyse de données Gérés centralement par ATLAS (Dan van der Ster et Johannes Elmsheuser) Executés par nuage depuis un framework de test basé sur Ganga incluant un outil de collecte et de présentation des résultats Véritable analyse analyse muons à partir AODS (tag soft ) Query dq2 : Input datasets (par ordre de priorité) sur les sites participants  mc08.*Wmunu*.recon.AOD.e*_s*_r5*tid*  mc08.*Zprime_mumu*.recon.AOD.e*_s*_r5*tid*  mc08.*Zmumu*.recon.AOD.e*_s*_r5*tid*  mc08.*T1_McAtNlo*.recon.AOD.e*_s*_r5*tid*  mc08.*H*zz4l*.recon.AOD.e*_s*_r5*tid*  mc08.*.recon.AOD.e*_s*_r5*tid*  mc08*AOD*e*s*r5 Génération de n jobs par site selon la disponibilité des datasets cibles  1 dataset = 1 job executésous DN : /O=GermanGrid/OU=LMU/CN=Johannes_Elmsheuser  CPUtime requis ~24h (typ. 5h) GlueCEPolicyMaxCPUTime >= 1440  Accès aux datasets depuis la zone ATLASMCDISK en mode rfio - Ecriture du fichier d’output sur ATLASUSERDISK

3 ST#82 des Decembre 08 Métriques / Cibles :  Nombre de jobs exécutés / Nbre de fichiers traités  Taux (evt/s) : cible 15 Hz  Taux de succès (success/failure rate) > 80 %  Utilisation CPU : CPUtime / Walltime > 50 % Durée globale du test : 48 heures 10 sites (TierofAtlas) participants  IN2P3-CC, IN2P3-LPC, GRIF-LAL, GRIF-LPNHE, GRIF-SACLAY, IN2P3- CPPM, IN2P3-LAPP, TOKYO, RO-O2, RO jobs demandés par site Mobilisation des experts sites et coordination FR-Cloud  via la liste wiki, échanges de Résultats :  Le test est passé (résultats raisonnables) mais les objectifs ci-dessus n’ont pas été atteints d’emblée  Problèmes et résultats très différents selon les sites (détails à suivre)

4 ST#82 des Decembre 08 Pb de disponibilité des input datasets - Tentative de réplication depuis CC infructueuse – pas de réel stress pour Marseille et le LAPP ! 28 jobs au IN2P3-LAPP 42 jobs au RO-07-NIPNE 45 jobs au RO-02-NIPNE 74 jobs au IN2P3-CPPM …. 237 jobs prévus pour GRIF-SACLAY 238 jobs au IN2P3-LPC 247 jobs prévus pour GRIF-LPNHE 300 jobs prévus pour GRIF-LAL 300 jobs au IN2P3-CC 300 jobs au TOKYO-LCG2 Suggestion sites : travailler avec un jeu de datasets identique sur tous les sites dont on s’assure de la disponibilité – Travail de réplication en cours de la part de Stéphane Tokyo meilleur T2 ATLAS !  Objectifs atteints  Site ATLAS uniquement, Configurations hardware serveur dpm et serveurs disques bien dimensionnées – Bonne répartition des données sur les différents serveurs de disques

5 ST#82 des Decembre 08 GRIF : stratégie et configuration multi-site 3 ToAs identifiés par les 3 SEs supportant ATLAS  GRIF-LAL, GRIF-SACLAY, GRIF-LPNHE  Ganga identifie ensuite les CES GRIF pouvant traiter les datasets présents sur les SEs ATLAS Les CES du LAL, SACLAY, IPNO, LLR supportent ATLAS et sont configurés (via les closeSE déclarés) pour accéder indifféremment ces 3 SEs ATLAS à travers GRIFOPN  Mapping CE-SE : pas de correspondance 1-1 (sauf pour le LPNHE qui ne publie pas de multiples SE pour le moment) Certains jobs exécutés à l’IPNO et au LLR. L’ensemble ou la quasi- totalité des jobs ciblés pour SACLAY ont été exécutés au LAL  accès aux données d’entrée depuis le closeSE  Écriture de l’output sur le defaultSE Configuration GRIF transparente pour ATLAS. Pas de stress test par CE Pas de stress test pour SACLAY mais un test efficace de GRIFOPN (limitation à 2 Gb/s du lien LAL – SACLAY annoncé à 5 Gbit/s observée et corrigée) Erreurs au LPNHE : pb ponctuel de configuration du site identifié et corrigé Avis GRIF nécessaire pour la suite…

6 ST#82 des Decembre 08 CC-IN2P3 : perf. moyennes pour différentes raisons  co-location T1 /T2 mal gérée par le framework de test (jobs envoyés sur cclclceli01 réservé au rôle production (problème identifié)  Problèmes ponctuels sur le site identifiés : cclcgli06, topbdii  Production MC toujours ON alors qu’il était prévu qu’elle soit arrêtée Erreurs rfio :  rfio timeout visibles dans les fichiers stderr même pour des jobs marqués « completed » (LPC, LAL) file rfio://clrgpfssrv03-dpm.in2p3.fr//storage/atlas1/atlas/ / AOD _00003.pool.root can not be opened for reading (Timed out)  Tous les fichiers du dataset ne sont pas lus Number of Files PROCESSED # EXPECTED by "completed" jobs  Tuning rfio possible à considérer par les sites (appliqué avec succès sur le nuage UK)  Augmentation du cache de lecture rfio de 128 Ko à 128 Mo sur les WNs

7 ST#82 des Decembre 08 Jobs bloqués (en l’état running)  Tués par le scheduler de batch au bout du MAxCPUTime autorisé  Qques uns au CPPM, 37 % au LPC  Travail de fouille de Jean-Claude et Edith pour récupérer les fichiers stdout et stderr sur les WNS  Pb du à un mauvais turl restitué par la commande lcg-gt lors de la phase de préparation « Prepare Inputs »  lcg-gt sollicite le topbdii (infos sur le serveur srm) et l’interface srm du SE  adaptation du fail-over de Ganga  Peut être lié à l’utilisation de topbdii distants dans le cas de LPC (topbdii CC !), CPPM (topbdii LAL)  option –nobdii Réflexion ATLAS et tests en cours en vue de l’optimisation de l’accès aux fichiers d’input – Modification possible du script de stage-in  Eviter la charge induite par les commandes lcg-gt  Revenir au protocole d’accès gsidftp…

8 ST#82 des Decembre 08 Beaucoup de résultats à exploiter Identification des erreurs  Accès aux logs Analyse (à poursuivre) les différents temps d’éxécution collectés par les jobs  Athena Software Setup Time : accès à la software area, setup cmt, untar gz…  Prepare Inputs Time : récupération des turl des fichiers input  Athena Running Time : execution athena  Athena Running Time, Normalized to Number of Events  Output Storage Time : lcg-cr du fichier output Réaction et Suggestion des sites  Nécessité d’avoir une description précise de « ce que fait le job d’analyse »  Set-up Athena : Stress de la zone software  Stress lors du pic de démarrage de centaines de jobs configuration du scheduler pour s’assurer de la répartition des jobs sur les WNs, introduire un léger décalage en temps  Moyen permettant aux responsables des sites ou au responsable de l'activité d'analyse au sein de ATLAS-France de réaliser ces tests de façon autonome,  Même jeu de données, afin d'avoir des résultats significatifs comparables entre les sites.

9 Comment poursuivre ? Concertation avec ATLAS : feed-back sous la forme d’un rapport de test Concertation avec les sites via visio T2-T3 Evolution du mode opératoire (suggestions sites) ?  autonomie nuage FR, sites…  Choix d’un jeu de données unique commun aux sites Evolution de l’accès aux données ? (réflexion ATLAS) Poursuite des tests en vue de l’optimisation des performances des sites  Demande SACLAY, LAPP, CPPM, LPSC