Activités présentes et à venir 13-9-2007 Ghita Rahal CC-IN2P3

Tests Accès base de données Oracle But: démontrer la possibilité pour des jobs d’Athena de faire des accès multiples et simultanés aux bases de données nécessaires au processing des événements. Setup de test de la méthode: Soumission des jobs en local sur BQS Queue privilégiée pour accès rapide 1er round de tests en Juin-Juillet 2007 Surchage dûe a un manque d’optimisation de la version 2.1 de COOL

Tests Accès base de données Oracle (suite) 2ème round de tests en Aout avec COOL 2.2 Résultats encore préliminaires Moins bons résultats au CC qu’à CNAF Différences dans les plans de requêtes Encore sous investigation. Les tests continuent…

Test M4: Un exemple de rayon cosmique

M4 run by the day Troughput in MB/s from T0 to all T1’s End Of the Données rayons cosmiques (muons) collectées par le detecteur d’Atlas du 23 Aout au 3 Septembre. données collectées (RAW) stockées sur bande au CERN et envoyées aux T1 au prorata de leur capacité (~10%). Données processées et stockées au CERN et les ESD produites envoyées vers les T1. ESD envoyées depuis les T1 aux T2 pour analyse ultérieure au niveau des T2 Troughput in MB/s from T0 to all T1’s End Of the run Expected max rate

M4 tests rayons cosmiques Résultats préliminaires: Moins de données prises que prévu mais amélioration vers la fin 66 TB RAW, 6 AOD+ESD => 100% des données demandées pour le CC Le transfert des données vers les T1 a fonctionné mais problèmes: Pas de visibilité des problèmes des transferts CERN (pas de monitoring comme au CC) Erreurs données par ARDA difficiles à interpréter. Transferts mélangés à des transferts de test: efficacité non mesurable Transferts T2-FR/T2-nonFR (pas dans le modèle d’Atlas° au niveau de Atlas; pas encore de résultats complets. Le transfert des T1 vers les T2: problèmes (liés à Atlas et problèmes liés à des transferts disk CC- tape CC de Atlas) http://dashb-atlas-data-test.cern.ch/dashboard/request.py/dataset?site=TOKYO&dsn=M4%&state=COMPLETE&state=INCOMPLETE&state=QUEUED&state=CANCELED&state=BROKEN&fromDate=&toDate=&offset=330&limit=30&orderField=modified_time%20DESC& L’analyse des données a pu s’effectuer dans 2 T2s. Plus de résultats ce soir….. Futur: Test de reprocessing de ces données dans 1 des T1s

Activités cosmiques futures M5: 16 au 23 Octobre M6: fin Décembre2007 /janvier 2008 En 2008: les données cosmiques seront prises en continu. Challenge: Améliorer les conditions: se rapprocher des taux nominaux, plus de T1 impliqués, plus de données, meilleure transferts aux T2,… Intercaler les reprocessing dans les T1 pour chaque prise de données.

FDR (full dress reherasal ) 2 slides suivants résument ce qu’est le FDR qui se déroule du printemps 2007 au printemps 2008.(infos prises sur les présentations WLCG Victoria) Jusqu’à maintenant la préparation concernait la préparation du software nécessaire et le T0. Étapes: Sept/Oct 2007: préparation des données et reconstruction dans le T0 et transferts aux T1s; Nov 07/ Fev 08 Reprocessing dans les T1 et DPD

FDR production goals (K.Bos-WLCG-Victoria) Simulated events injected in the tdaq Realistic physics mix Bytestream format including luminosity blocks File & dataset sizes as expected for real data Realistic trigger tables datastreaming Use of conditions database Data quality-, express line-, callibration- running T0 reconstruction: ESD, AOD, TAG, DPD Exports to T1&2’s Remote analysis

FDR analysis goals (K.Bos-WLCG Victoria) at the T1’s Reprocessing from RAW  ESD, AOD, DPD, TAG Remake AOD from ESD Group based analysis DPD At the T2&3’s Root based analysis Trigger aware analysis with Cond. and Trigger db No MC truth, user analysis MC/Reco production in parallel

Tests FZK/BNL/LYON En Stand By à cause des problèmes inhérents à DDM.

Spécifique au CC Restructuration des pools de dCache Perte de fichiers: difficulté 1: les fichiers disparus ne sont identifiés que lorsqu’ils sont accédés (~600)=> beaucoup de nettoyage pour dCacheMasters Beaucoup de nettoyages registres (LFC, DDM...) Problèmes pour les utilisateurs: recréation ou réplication des données depuis les autres T0/1 Script par les dcachemasters pour connaître l’utilisation des pools La plateforme SL4/ 32 commence à être utilisée par la prod et les utilisateurs. Lenteurs et blocages AFS: augmentation du nombre de serveurs, réplication des répertoires,….

Étude des batch jobs Extraire via qselect les information sur les jobs dans BQS et créer un fichier. Faire des fichiers pour un groupe ou une classe sélectionnée. Faire les graphes des différentes grandeurs. Ici: Atlas050, cms050, lhcb050, aligrid Jobs Classe T Jobs soumis entre le 1/1/2006 et le 15/9/2007

Statut (stat2) des jobs

Temps d’attente des jobs 8 min 5 min 2 min 5 min

CPU temps et efficacité

Mémoire Max utilisée

Mémoire Max vs temps CPU utilisé