1 Accounting DGAS per job MPI Marco Bencivenni (INFN-CNAF) Workshop CCR-INFN GRID Maggio 2010

2 Sommario Qual è il problema Obiettivo del lavoro Parametri testati Testbed e metodologia Risultati ottenuti Conclusioni Lavori futuri

3 I sistemi di acconting Grid in uso attualmente non permettono di differenziare i dati di accounting per tipologia di job (parallelo vs sequenziale) L’accounting di job MPI è importante per stimarne il relativo workload sull’infrastruttura Grid e per capire quali discipline Grid fanno maggior uso di MPI al fine di migliorarne il supporto. Tra le varie cose questo significa anche fornire strumenti di accounting adeguati tramite una estensione di DGAS (Distributed Grid Accounting System) Problema

4 Obiettivi Primo passo necessario per l’estensione dei sensori DGAS e del portale HLRmon è la validazione dei dati collezionati dai sensori di DGAS per i job MPI, su diversi batch system, in modo da renderli pubblici in HLRmon differenziandoli da quelli sequenziali. – Capire se i dati collezionati dai sensori si riferisco ad un singolo processo o sono la somma dei processi di ciascun job MPI – Per i job paralleli può risultare che il CPUTime sia molto maggiore WallClockTime e quindi utilizzare il CPUtime per misurare il tempo effettivo di utilizzo delle risorse

5 Campi già presenti nello usage records di HLR: – CPUtime: Amount of CPU time used by all processes in the job. – WallCLockTime: Amount of real time during which the job can be in the running state. – executingNodes: The Worker Node(s) where the user payload is executed. – Pmem: Amount of physical memory used by any single process of the job – Vmem: Amount of virtual memory used by all concurrent processes in the job Possibili campi futuri: – Processors: Number of processors where the user payload is executed Parametri

6 Sono stati creati 3 testbed, uno per ciscun Batch System e per ognuno sono stati testati i valori di CPUTime, WallclockTime, executingNodes e Processors E’ stato simulato un caso di uso reale: – un job MPI con 2 processi di durata diversa ma nota per entrambi (120 e 180 sec); ciascun processo utilizza una diversa CPU – (Ringraziamenti a Cristina Aiftimiei e Gian Mario Mereu) Metodolgia Batch System #Worker Node #CPUFlavour MPI Sede PBS12openmpiCNAF LSF12openmpiPadova SGE24mpichCybersar- portoconte

7 Risultati: PBS - LSF PBSLSF CPUTime WallClockTime executingNodespre-wn- 02.cnaf.infn.it/1+pre-wn- 02.cnaf.infn.it/0 cert-wn32-05;cert- wn32-05 pmem vmem

8 Risultati: SGE cybersar:wnsge02.ca.infn.it:cybersar:cybe rsar006:STDIN:377:s ge:0: : : :0:0:130:33:87: :0:0:0:0:161938:0:0 : :0:0:0:0:250 8:872:NONE:defaultd epartment:mpich:2:0: : : :-q cybersar -pe mpich 2: :NONE: WN WallClockTime CPUTime

9 LSF e PBS: – I dati di CPUTime sono quelli previsti – Sono molto differenti tra loro i valori pmem e vmem SGE: – Pubblicazione dei dati per il solo processo “0” – Nessun CE SGE di produzione in Europa supporta MPI pmem/vmem – Al momento non ancora identificato come realizzare un job che richieda un utilizzo esatto delle memorie Osservazioni

10 Conclusioni I dati pubblicati in HLR per executingNodes, CPUTime e WallclockTime sono corretti per LSF e PBS, per tali sistemi è dunque possibile raccogliere dati di accounting accurati A livello di database (HLR) i job MPI verranno differenziati da quelli sequenziali utilizzando il campo processors non appena questo sarà integrato ufficialmente in HLR

11 Portale di accounting HLRmon [ ts.php]: aggiunta di specifici grafici per job MPI Accuratezza: verificare la correttezza dei valori pmem e vmem SGE: è necessario attendere un miglior supporto ad MPI ed un perfezionamento dei log prodotti Lavori Futuri

12 ? Domande