Referaggio CMS 2017 TOMMASO BOCCALI – INFN PISA 9 SETTEMBRE 2016 1.

Presentazione sul tema: "Referaggio CMS 2017 TOMMASO BOCCALI – INFN PISA 9 SETTEMBRE 2016 1."— Transcript della presentazione:

1 Referaggio CMS 2017 TOMMASO BOCCALI – INFN PISA 9 SETTEMBRE 2016 1

2 Outline Stato 2016 ◦Fino ad ora ◦Piani fino ad Aprile 2017 ◦Cambiamenti principali nelle operazioni / SW Stato risorse Italia Utilizzo risorse Italia 2017 ◦Piani LHC ◦Richiesta risorse ◦E in particolare, update 2017 e 2018 2

3 2016 so far LHC Post – Chamonix LHC estimate : Lumi for 2016 very similar to 2012 … mica tanto! 3

4 2016 in the model by LHC 4.8-5.1 Msec di stable beams; PU ~30 ◦5.1 Msec = 1400 ore Fine luglio: 1000 ore ◦Luglio = 430 ore di SB in 21 giorni ◦Luglio = 85% di live time sui 21 giorni ◦Fine Luglio = Hubner factor 0.67 (expected = 0.37) ◦A partire da Aprile (inizio Run) ◦Agosto: ~350 ore SB ◦(e lo definiamo “brutto”) ~300 ore ~430 ore ~350 ore 4

5 Interfill … CMS ha lavorato moltissimo (anche su spinta dello Scrutiny) per commissionare utilizzo della farm HLT durante interfill … Peccato che l’interfill non esiste piu’: ◦Anche meno di un’ora fra beam dump e iniezione ◦Anche meno di due ore fra 2 SBs Tirare su O(5000) VM assegnare lavoro via Condor fare shutdown in tempo e’ per il fill dopo E’ una parte consistente di 2 ore … il gioco comincia a non valere la candela (ma vedi dopo) 5

6 29 Luglio, nuove stime LHC per il RunII In pratica, LHC marcia un anno in anticipo: i secondi totali di presa dati aspettati a fine 2018 sono adesso a fine 2017 Rule of thumb: richieste 2018 di calcolo anticipate a 2017 (almeno per le categorie incomprimibili, tipo tape) 6

7 Ad oggi (Sept 5nd) … Agosto: 350 ore di SBs ◦Molti casini, nonostante tutto meglio di Giugno! Attese ancora ~5 settimane piene di presa dati (al 5 Settembre). A 0.5/fb/day, 16/fb aggiuntivi? O piu’: Sept 3 rd record a 1.33e34 Potenzialmente fino a 20% in piu’ da diminuzione crossing angle ◦Esperimenti preparati a ricevere fino a 1.6e34 7

8 Attivita’/Problemi di CMS ad oggi… Sopravvivere alla presa dati: ◦Risorse 2016 chieste per 5Msec, gia’ esauriti la prima settimana di settembre (1400 ore il 4 Settembre = 5 Msec ) ◦CPU: non un (enorme) problema; fino a Jun 2016 PU piu’ basso, e miglioramenti di performance nel codice ◦Messi nel modello a partire dal 2017, ma gia’ oggi ~ 20% piu’ performanti su Ricostruzione ◦Inoltre, samples per TDR di PhaseII ritardati e in partenza a breve, CPU T1 “liberata” nella prima meta’ dell’anno ◦Pesante overpledge sui T2 non dichiarato ma evidente ◦Purtroppo siamo ben lontani da MC/DT=130% ancora … ◦Storage: un grosso problema ◦Disco T1: ◦underpledge 10% (e non tutto “materializzato”) ◦problema con spazio di Buffer per il tape maggiore del previsto ◦reprocessing dei dati/MC 2015 aggiuntivo (fuori dal modello) di cui non riusciamo a liberarci ◦Compensazione: riduzione drastica del numero di copie AOD ◦Disco T2: si sopravvive, ma solo perche’ il numero di copie degli AOD da modello (~1.5) e’ in pratica ridotto ad 1 ◦Tape T0: ◦a questo ritmo, pieno a fine Settembre (siamo a 41/44 PB) ◦Cancellazione di O (6) PB di emergenza a Settembre/Ottobre ◦Tape T1: a questo ritmo finisce ~ Novembre ◦Cancellazione di O (10-15) PB di emergenza a Settembre/Ottobre ◦Richiesta alle FA di avere anticipo 2017 dove possibile Cancellate cose che non avremmo voluto cancellare, come RECO del RunI, etc. Chiaramente nessuna cancellazione di RAW, e il piano e’ di continuare assolutamente ad averli in doppia copia 8

9 Attivita’/Problemi di CMS ad oggi… 2015: passaggio a global pool HTCondor, per cui possibilita’ di gestire quote / priorita’ etc sia ai T1 sia ai T2 2016 (prima meta’): passaggio quasi completo a pilots multicore (8 cores); payloads ancora single core 2016 (seconda meta’): attivazione di payloads MultiThreaded (4 vie) per la produzione ◦Minore numero di jobs in Condor ◦Minore RAM usata ◦Minore numero di files aperti ◦Data management semplicificato 9

10 Produzione MC Mar 2016 comincia prima fase ◦O(10 B) events, PU medio ~ 20 Settempre 2016: seconda fase ◦> 6 B events, PU medio > 30 ◦(tutto questo in presenza di produzione “2015” ancora attiva per finalizzazione analisi) ◦(purtroppo, questo vuol dire che come al solito il rapporto MC/DT, fissato da modello a 130%, e’ ampiamente sforato) Una frazione di questi eventi in modo atipico: samples prodotti e a posteriori applicata simulazione HLT (non pronta inizialmente). Ha richiesto il salvataggio di un nuovo formato (RAWOADSIM) per O(2 PB), temporaneo. 10

11 Stato del detector (e implicazioni sul computing) 2015: problema del magnete ◦Simulazioni con e senza magnete, per l’oggetto a 750 GeV 2015: beam spot reale spostata di O(1 cm) rispetto a stime da LHC ◦Reprocessing completo del MC necessario 2016: ◦Problema Tracker, con inefficienza di elettronica per la prima meta’ dell’anno ◦Oggi completamente risolto, ma probabilmente necessario ulteriore reprocessing (dati) della prima meta’ dell’anno con mitigation software al problema ◦In partenza meta’ settembre 11

12 Utilizzo Risorse - CPU T2: forti overpledge (soprattutto lato US, ma anche IT) 122% ultimo anno 10-15% overpledge in Rebus nel 2015, quasi di nulla nel 2016 (quindi si tratta di overpledge “non ufficiale” – non ci si puo’ contare) T1: Overpledge molto scarsi CPU underpledge in Rebus nel 2016 del 6% Buchi verso Aprile-Maggio: ritardo nella messa in linea delle risorse per il nuovo “anno WLCG” Overall 101% del pledge utilizzato (ultimi 12 mesi) 12

13 Tape Tape @T1: trend dice che NON arriveremo a fine anno – doppio deficit: ◦88 PB pledged su 100 raccomandati (-12%) ◦85 PB reali (ritardi nelle “consegne” del pledge) ◦100 PB era la richiesta per un anno con 5Msec di presa dati e MC al 130% ◦Plot non lo dimostra in pieno: accounting WLCG arriva solo a Luglio, all’inizio dell’esplosione della presa dati! ◦Azioni ◦Cancellazioni di emergenza per almeno 10-15PB; dovrebbero ~ compensare l’underpledge ◦Resta il fatto che non e’ ovvio arrivare al 1 Aprile 2017 ◦Da qui a allora non solo presa dati, ma anche ◦Reprocessing dei dati ◦Nuovo MC ◦Samples di Phase II ◦… Nota: problema simile al T0, dove pero’ il CERN sembra in grado di fornire tape in piu’ 13

14 Disco T1: ◦Pledge -10% rispetto alle richieste ◦A altro -10% per pledge tardive (== non c’e’ ancora) ◦Siti sembrano “mettere da parte” una quota maggiore del previsto per buffer del tape ◦Sostanzialmente pieno, diversi panic mail gia’ adesso (KIT, PIC, …) ◦Azioni di pulizia in emergenza ◦Diminuzione del RECO su DISCO da 100% per 3 mesi, a ~50% ◦RAW tenuti su disco solo per 3 mesi; crea problemi non banali per reprocessing veloci ◦Numero di copie totali di AOD/AODSIM fra T1 e T2 molto diminuito.... Siamo critici! ◦T2: ◦Pieno, ma meno problematico ◦Come sopra, numero di copie totali di AOD/AODSIM fra T1 e T2 molto diminuito.... Siamo critici! ◦Non salvano RAW/RECO, per cui meno critici dal punto di vista della presa dati NOTE: non tutti I T1 mettono nell’used le aree temporanee, per cui utilizzo reale maggiore di quanto si veda qui Anche qui, ultimi numeri WLCG sono per Giugno; riempimenti avuti a partire da luglio 14

15 Numero utenti attivi per l’analisi In aumento nel RunII Quasi al livello del RunII ◦Ma adesso analisi molto meglio organizzate, con meno “sottomettitori”  attivita’ in aumento ◦400 utenti singoli utilizzano CRAB ogni settimana 15

16 Dynamic Data Management Tool che ◦Rimuove da disco repliche di dati non utilizzati abbastanza (fino ad un minimo di copie per data Tier) ◦Rimuove da disco anche l’ultima copia di dataset non toccati da 12 mesi (se hanno copia su tape) ◦Aumenta repliche di dataset ”popolari” ◦Fino ad agosto 2016: ◦~45 PB di dataset cancellati ◦~13 PB di dataset replicati Grosso aumento di attivita’ 2016 vs 2015 16

17 Tier-0 Di solito non se ne parla qui, ma critico nel 2016: ◦CPU: piu’ o meno ce la fa, grazie ai miglioramenti SW e al PU medio inferiore a 30 fino a meta’ luglio ◦Tape: come detto stesse problematiche di T1 tape, compensate (si spera!) da ◦Cancellazione emergenza anche qui ◦Disponibilita’ del CERN a sforare / anticipare 2017 ◦Disco: i PB di disco del Tier0 sono saliti da ~2 a ~7 PB (anche con prestito chiesto al CERN), per due motivi ◦Luglio 2016: difficolta’ di svuotamento del buffer verso I T1, per problemi di banda EOS (lo stesso per ATLAS) ◦Piu’ o meno mitigato dall’aumento dei server ◦Necessita’ di applicare simulazione HLT a posteriori (perche’ non pronta al momento del processing) ◦1-2 PB dati dal CERN temporaneamente Fino a Giugno2016: cap a 1.5 GB/s, a fronte di ~2 GB/s prodotti dal Tier0 Dopo Luglio 2016: banda grandemente aumentata ( > 3 GB/s) Agosto 2016: semplicemente non e’ servita per backlog finito, Settembre si sta risalendo T0->T1 17

18 Attivita’ Italia – un veloce riassunto Italia molto ben rappresentata nel Management di Offline/Computing 1 Project Manager - D. Bonacorsi 1 Focus Area Leader (Operations) – T.Boccali 5 Level 2: ◦C.Grandi, G.Bagliesi, S.Belforte, T. Boccali, A. Santocchia 18

19 Responsabilita’ calcolo 19

20 Attivita’ “notevoli” PD/BO ◦dynamic resource provisioning: test di sottomissioni Cloud (HLT, NERSC) ◦Non piu’ solo tests, operazioni su HLT in produzione PI/CNAF ◦Aruba, CloudItalia, adesso Microsoft ◦News: 20kEur di Grant assegnati da M$ al CNAF per test su Azure; ci stiamo preparando (ATLAS e’ nel giro…) TS/PG ◦Controllo/gestion/sviluppo di CRAB3 e di AsyncStageout ◦CNAF/PI/BA/PG ◦Sinergie con Indigo ◦PI/BA/CNAF ◦controllo del lato europeo della federazione di Xrootd (compreso CERN) ◦CNAF/MI ◦GPU per tracking a HLT (appena cominciato...) ◦PI ◦Bigdata analystics con Hapoop/Spark ◦PI/PG/CNAF/BA ◦Utilizzo di Indigo per CMS... 20

21 Stato Siti Italiani Tutto molto verde …. (non ovvio, vedi dopo) 21

22 Waiting room + Ranking Nota: waiting room = sito sotto attenzione Stato successivo (sito decommissionato per qualche tempo) mai raggiunto da siti italiani 22

23 Ultimi 12 mesi (da 1 set a 1 set) - # jobs T1+T2 La terza (CH) non vale perche‘ ci sono le risorse cern quando non c‘e‘ presa dati T2 La seconda (CH) non vale perche‘ ci sono le risorse cern quando non c‘e‘ presa dati La terza e‘ sostanzialmente il grosso analysis center di DESY T1 (ammazza la russia!) 23

24 Share italiano Bari un po’ sotto le aspettative Per il resto nulla di incomprensibile direi … 24

25 (il nostro amico) Faust #1 T1 sostanzialmente ok Minore attivita’ solo verso Natale e Agosto (… a voce...) 85% del pledge LNL oevrpledge anche in presenza di buchi sospetti dell’accounting 133% del pledge + buchi (?) 25

26 (il nostro amico) Faust #2 PI enorme buco a maggio, in via di soluzione (ma ticket apel aperto da >2 mesi!!) 110% del pledge + buco enorme (stima quindi almeno 120%) RM1 non puo’ andare overpledge, e ancora non acquisti 2016 (da fare)poca attivita’ maggio in poi per carenza di coda multicore (vedi dopo slide su roma) 60% pledge ma diventa ~80% se si tiene conto di CPU 2016 non ancora acquisite 26

27 (il nostro amico) Faust #3 In netto miglioramento da quando accesa coda multicore (e uso CPU spostato su ReCaS) 60% pledge CPU 2016 non ancora acquisite (20% delle risorse, era un + 4.75kHS06) 27

28 Ieri … CPU non ancora acquisite 28

29 Stato Roma - personale Ottobre 2015 ◦Tecnologo “preposto” va in aspettativa ◦Lo e’ tuttora, molto probabilmente si dimettera’ Grossi problemi al sito, che non dispone piu di persona dedicata Sforzo congiunto di vari staff ha permesso di mantenere il sito verde, ma non di effettuare modifiche drastiche alla configurazione ◦Per esempio, coda multicore ancora non attiva Da 1 Agosto 2016 nuovo assegnista ha preso servizio ◦A parte I tempi ovvi di ramp-up, sito ha prospettive piu’ rosee Nonostante questo, come detto a Maggio, si ritiene per il momento di limitare l’acquisizione dello storage, solo per quest’anno ◦Delta ridistribuito fra gli altri 29

30 Richieste 2017 – back on the envelope per nuovo LHC Quantita’ integrali (Tape, Disco T2, parzialmente Disco T1, CPU T2, …): ◦Secondi NEW(2016-2017) = Secondi OLD(2016-2018) ◦Scalare richieste 2018 a 2017 (+30% almeno) Quantita’ che scalano con eventi dell’anno in corso (CPU T1, …) ◦Dovrebbero aumentare del +40% (7.8/5.5) Quantita’ che scalano con efficienza di presa dati (CPU T0, Buffer Disco T0,...) ◦Dovrebbero scalare con Hubner factor (da 0.37 a 0.6x) quindi +80 % ◦In realta’ scalano con efficienza di presa dati in un dato periodo, pero’ dettaglio tecnico 30

31 Una piccola nota … 200X – 2015: CMS Italia al 13% di CMS 2016: calata al 12% (il numero vero era 12.3%) 2017: nuovi numeri (Tenchini) “Italy e’ aumentata del 7% rispetto al 2016 come numero di PhD, siamo al 12.90% di CMS (la frazione 2016 e’ 12.3%)” Ci sarebbero gli estremi per andare al 13% di nuovo … ma francamente non mi pare il caso, viste le slides successive Se non adesso, sara’ per 2018 31

32 Richieste 2017 – Spring 16 version Spring16: richieste 2017 – 2018 basate su vecchio LHC model Richieste approvate da C-RSG Discussione di Maggio e richieste preventivi basate su queste … nei preventivi... 32

33 Tagli … In ordine di “facilita’” e “minore impatto” 1.CPU dismissione 2017: 11.2 kHS06 (112kEur) 2.Overhead: da 120k a dove non si puo’ fare a meno di scendere 3.… a voce... 1+2: 33

34 Richieste 2017 Cambiamento maggiore e’ quello relativo al nuovo modello di LHC ◦Quasi tutto il resto e’ mitigazione di questo effetto CPU: ◦mitigazioni da migliori performance SW, minore numero di passaggi sui dati in analisi Disco: ◦RAW e RECO transienti su disco (e solo una loro frazione) ◦Utilizzo maggiore del T0 e minore dei T1 (anche per limitare export dal T0 che e’ stato problematico) ◦Meno copie distribuite di AOD e MiniAOD Tape: ◦Poca magia disponibile, per cui in pratica scalano al 2018 (per fortuna costano poco…) ◦Qui poi c’e’ il macigno dell’underpledge cronico, scendere sarebbe da pazzi... Aggiunte al modello (presa atto della realta’) ◦Maggiore spazio Disco ai T1 per aree temporanee ◦Maggiore disco/tape al T0 per samples di ALCARECO (che sono anche piu’ grandi) visto il loro utilizzo maggiore del previsto 34

35 O meglio, rispetto a Spring16 – numeri per 2017 Vecchia richiesta Spring16 C-RSG Spring16 Nuova richiesta Fall16 Aumento relativo (probabilmente nessun senso statistico…) Aumento assoluto kSH06 TBN TB Solo una categoria sfora 30% (perche’ T0 disk aumenta molto in buffer e si prende carico dei RECO) 35

36 Nuovi numeri con stesse approssimazioni / dismissioni 36

37 T2 - tagli …. Cosa “togliere”? ◦Dismissioni CPU 2017 prima vittima designata ◦~ 110 kEur in meno ◦Azzerare overhead ◦~ 180 kEur meno ◦Gulp, tutto?? ◦Altro? ◦(lo dico a voce…) 1297 kEur 37

38 T1 … Purtroppo non ho idee ovvie ◦(non ho dismissioni / overhead da tagliare) ◦Banalita’: ◦Anche visto underpledge degli ultimi anni, tagliare al T1 piu’ doloroso che tagliare ai T2 ◦La situazione tape per CMS e’ davvero disastrosa; siamo fortunati se arriviamo a fine 2016, e in ogni caso avremo delle cambiali da restituire (anticipi) ◦L’ovvia priorita’ per noi e’ 1.TAPE indispensabili 2.Disco quasi 3.CPU qualcosa overpledge becchiamo sempre …. 38

39 Conclusioni (?) Situazione problematica, in gran parte NON dovuta agli esperimenti ◦Siamo passati dal RunII al RunIII senza accorgercene … ◦Commento tipico al CERN e’ “avercene di questi problemi…” (ma chi lo dice poi non deve cercare le risorse…) CMS ha provato a mitigare gli aumenti che sulla carta erano nel range 30-80% a una media intorno al 20% ◦Oltre a questo, ben poca garanzia che le cose non tracollino (soprattutto TAPE e DISCO) Ovviamente e’ una situazione molto atipica, anche in presenza di un referaggio C-RSG positivo, poche garanzia che le FA mettano davvero in campo le risorse 39