Test del Monitoraggio del Tracker usando un Tier2 M.S. Mennea, G. Zito, N. De Filippis Università & INFN di Bari Riunione Consorzio – Torino 18 Novembre 2005

Perchè fare un monitoraggio distribuito

Possibile soluzione Monitoraggio a due livelli 1. monitoraggio in control room monitorare cose più importanti/urgenti 2. monitoraggio sulla grid (Tier2,Tier1,Tier0,cluster specializzato al cern) monitorare dettagliatamente i 9,6 Mln di strip e i 50 Mln di pixel risorse necessarie per un Tier2: 10% raw data trasferiti con un rate di 1TB/day CPU time di circa ~100 PC full time spazio disco necessario 1TB/year

Es di Monitoraggio con un Tier2 Control room Bari Tier 2 Filter Unit Farm …. CPU 10% raw data 1 TB/day …. DQMHistograms Tracker Map.root, *.jpg Browser Master Machine Server Web CPU SE UI JDL DropBoxAgent RB SVG Map Tier 1Tier 0

1. Costruire circa 3-4 istogrammi per modulo ogni pochi minuti e memorizzarli su disco 2.Trasformare i dati (gli istogrammi) in una immagine (png) vista immediatamente dalla control room in un dashboard display 3.la stessa immagine in formato SVG permette alloperatore, in caso di problemi, di accedere agli istogrammi per i moduli causa degli stessi 4. tutte le informazioni dellanalisi del Tier2 sono conservate sullo stesso Tier2 sotto forma di immagini SVG e istogrammi collegati alle stesse accessibili via web per una successiva analisi Possibile strategia per un monitoraggio di secondo livello

Risultati preliminari Dataset H->ZZ->2e2mu with PileUp - 10,000 events (about 50,000 hits for events) Jobs250 (41 layers x 5 jobs_ (2000 events) ) Tempo reale del test95 min con 35 jobs in parallelo CPU60% del tempo reale WN & Master MachinePentium IV 2,4 GHz-3,0 GHz with 2GB RAM Memoria~ 300 MB per job Tempo impiegato da un unico Job x processare gli stessi eventi su ununico pc = 120 min Tempo minimo teorico con 35 pc = ~3,5 min Ad es. Se il singolo Job si riferisce allintero tracker si ha un miglioramento di un fattore 5 nel tempo totale. Ottimizzare diversi parametri

Limiti e problemi incontrati da ottimizzare * Usata solo 1/3 della CPU totale rate di accesso dei dati, di 100 MB/s sul server e 10 MB/s per nodo. può essere ottimizzato usando differenti protocolli di accesso (rfio, dCache) * Problemi della grid: RB, overhead per la sottomissione (9.9 s), recupero dei file di output * Numero dei Job in parallelo * Saturazione della banda di rete nel trasferimento dati (ora è di ~100GB) * overhead introdotto da applicativi usati per lanalisi sincrona

Conclusioni È stata definita una possibile strategia di monitoraggio di secondo livello per il tracker È stato fatto un test col Tier2 di Bari Bisogna ottimizzare molti parametri Questo tipo di monitoraggio può essere fatto anche su un cluster di macchine locale