Millora de la gestió de recursos a SLURM

T´ıtol: Millora de la gesti´o de recursos a SLURM Volum: 1/1 Alumne: Carlos Fenoy Garc´ıa Director/Ponent: Julita Corbalan Gonz´alez Departament: Arquitectura de Computadors Data: Juny 2010 DADES DEL PROJECTE T´ıtol del projecte: Millora de la gesti´o de recursos a SLURM Nom de l’estudiant: Carlos Fenoy Garc´ıa Titulaci´o: Enginyeria Superior en Inform`atica Cr`edits: 37,5 Director/Ponent: Julita Corbalan Gonz´alez Departament: Arquitectura de Computadors MEMBRES DEL TRIBUNAL (nom i signatura) President: Xavier Martorell Bofill Vocal: Anna de Mier Vinu´e Secretari: Julita Corbalan Gonz´alez QUALIFICACI ´ O Qualificaci´o num`erica: Qualificaci´o descriptiva: Data: Millora de la gesti´o de recursos a SLURM Carlos Fenoy Garc´ıa Juny 2010 iv ´ INDEX DE FIGURES 4.17 MEDIUM: Vista de l’´us d’ample de banda de cada Node en els diferents workloads. 45 4.18 MEDIUM: Vista de l’´us d’ample de banda de mem`oria del sistema en dues execucions. ......................................... 46 4.19 MEDIUM: Slowdown en cada una de les execucions . . . . . . . . . . . . . . . . 46 4.20 MEDIUM: Estat de finalitzaci´o dels treballs . . . . . . . . . . . . . . . . . . . . . 47 4.21 MEDIUM: Percentatge d’utilitzaci´o de les CPUS . . . . . . . . . . . . . . . . . . 47 4.22 MEDIUM: Vista de l’´us de cada CPU en els diferents workloads. . . . . . . . . . 48 4.23 LOW:Vista del process de les aplicacions en els diferents workloads . . . . . . . . 49 4.24 LOW:Vista de l’´us d’ample de banda de cada Node en els diferents workloads. . 50 4.25 LOW: Vista de l’´us d’ample de banda de mem`oria del sistema en dues execucions. 51 4.26 LOW: Slowdown en cada una de les execucions . . . . . . . . . . . . . . . . . . . 51 4.27 LOW: Estat de finalitzaci´o dels treballs . . . . . . . . . . . . . . . . . . . . . . . 52 4.28 LOW: Percentatge d’utilitzaci´o de les CPUS . . . . . . . . . . . . . . . . . . . . . 53 4.29 LOW: Vista de l’´us de cada CPU en els diferents workloads. . . . . . . . . . . . . 53 5.1 Planificaci´o temporal del projecte . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 CAP´ ITOL 1 Introducci´o Aquest projecte pret´en implementar i avaluar una millora en la selecci´o de recursos d’un gestor de recursos orientat a supercomputadors com MareNostrum, situat al BSC-CNS1, basant-se en l’´us de recursos compartits. 1.1 Motivaci´o El m´on de la supercomputaci´o avan¸ca molt r`apidament, s’ha passat de dos a dotze processadors per node i de prop de 5000 nodes a m´es de 25000 en els darrers 5 anys. Aquests augment en el nombre de recursos ha provocat que la gesti´o dels recursos sigui cr´ıtica per obtenir el m`axim rendiment d’un supercomputador, i per maximitzar el nombre d’hores ´utils de c`alcul. Si ´es t´e en compte que l’´us del supercomputador es determina per una assignaci´o de determinades hores de c`alcul a cada un dels usuaris de la m`aquina, es posa de manifest que la gesti´o de recursos no ´es tan sols important per la gesti´o del centre, sin´o tamb´e pels usuaris, ja que una bona gesti´o de recursos provocar`a que aquests puguin obtenir m´es rendiment de les seves hores assignades. L’augment en la freq¨u`encia dels processadors ha provocat tamb´e que altres recursos resultin cr´ıtics durant l’execuci´o dels programes. Un d’aquests recursos cr´ıtics ´es l’ample de banda de mem`oria, que augmenta d’una manera m´es pausada respecte la freq¨u`encia dels processadors, fet que provoca que aquest sigui un recurs realment cr´ıtic, en esdevenir un dels principals colls d’ampolla d’algunes aplicacions. Per tant, una gesti´o de recursos conscient de l’ample de banda de mem`oria disponible en cada node, i dels requisits de cada aplicaci´o, ser`a capa¸c de repartir les 1http://www.bsc.es 1 2CAP´ ITOL 1. INTRODUCCI ´ O diferents tasques d’aquesta per maximitzar-ne el seu rendiment, reduir el seu temps d’execuci´o i aconseguir que m´es aplicacions es puguin executar en un interval de temps. L’exist`encia de pol´ıtiques te`oriques enfocades a pal·liar aquestes problem`atiques, conjuntament amb l’exposat anteriorment, s´on els motius que han impulsat la realitzaci´o d’aquest projecte, per analitzar el comportament d’una pol´ıtica concreta, basada en la reducci´o de les penalitzacions inherents a la compartici´o de recursos, que no ha estat mai implementada en un entorn real. 1.2 Objectius Donada la import`ancia de la selecci´o de recursos per a l’`optim funcionament d’una m`aquina d’alt rendiment, l’objectiu ser`a implementar una pol´ıtica de selecci´o de recursos capa¸c de reduir la penalitzaci´o provocada per la compartici´o de l’ample de banda de mem`oria entre diferents tasques dins d’un node de c`alcul. Les pol´ıtiques de selecci´o de recursos m´es utilitzades avui en dia nom´es tenen en compte el n´umero de recursos disponibles, els consideren consumibles que s’assignen a cada treball. Nom´es es consideren recursos no compartits o recursos compartits sense permetre una assignaci´o superior al disponible en un node. No es te en compte si l’assignaci´o realitzada pot comportar alguna penalitzaci´o per la compartici´o d’algun recurs del que no se’n tenen dades, com per exemple l’ample de banda de mem`oria o la xarxa de comunicacions. Aix´ı doncs, l’objectiu d’aquest projecte ´es implementar un pol´ıtica de selecci´o de recursos que tingui en compte la disponibilitat d’un recurs compartit, com ´es l’ample de banda a mem`oria, i l’´us que en fan les aplicacions, i posteriorment analitzar-ne el seu comportament. D’aquesta manera es pret´en obtenir una pol´ıtica de selecci´o de recursos ampliada amb noves funcionalitats sense renunciar a les qu`e ja s’ofereixen actualment. 1.3 Metodologia La metodologia seguida per a la realitzaci´o d’aquest projecte ha estat la seg¨uent: 1. Estudi exhaustiu de la pol´ıtica Less Consume2, per entendre completament el seu funcionament. 2. Estudi del gestor de recursos SLURM3, del seu sistema de plugins i an`alisi de viabilitat de la implementaci´o de la pol´ıtica Less Consume. 3. Identificaci´o dels nous requisits dels treballs per tal de poder utilitzar la pol´ıtica, i implementaci´o d’aquests: modificaci´o de comandes per acceptar nous par`ametres i modificaci´o 2Job-Guided Scheduling Strategies for Multi-Site HPC Infrastructures, [Gui] 3Simple Linux Utility for Resource Management, [SLU] 1.4. ORGANITZACI ´ O DE LA MEM ` ORIA 3 del controlador per a emmagatzemar-les i tenir-les en compte. 4. Implementaci´o d’una primera versi´o de la pol´ıtica capa¸c d’assignar recursos segons l’ample de banda requerit per cada treball. 5. Implementaci´o de millores a la pol´ıtica abans implementada, afegint opcions de configuraci´o per modificar el comportament de la pol´ıtica segons les necessitats mitjan¸cant par`ametres. 6. Modificaci´o d’un plugin d’accounting encarregat d’enregistrar els events del treballs, que implementi un format est`andard d’accounting per poder analitzar el comportament de la pol´ıtica i els seus diferents par`ametres. 7. Preparaci´o de l’entorn d’avaluaci´o. 8. Realitzaci´o de les proves i avaluci´o dels resultats. 1.4 Organitzaci´o de la mem`oria Aquest document esta estructurat en els seg¨uents apartats: •Introducci´o: En aquest cap´ıtol es fa un rep`as dels objectius del projecte i la motivaci´o. Tamb´e es descriu m´ınimament la metodologia utilitzada per realitzar-lo. •Entorn del projecte i estat de l’art: es d´ona una introducci´o als conceptes que seran necessaris per entendre aquest projecte. •Desenvolupament del projecte: en aquesta secci´o es descriu tot el desenvolupament dut a terme per a la implementaci´o del projecte. •Avaluaci´o i an`alisi de resultats: aqu´ı es presenta el desenvolupament previ per a la preparaci´o de les proves, la preparaci´o de l’entorn d’execuci´o d’aquestes i l’an`alisi dels resultats. •Estudi econ`omic i planificaci´o: aquest cap´ıtol d´ona m´es detall sobre la planificaci´oi seguida en la realitzaci´o del projecte aix´ı com el corresponent an`alisi econ`omic del desenvolupament. •Conclusions: Aquesta secci´o sintetitza els resultats obtinguts i extreu les conclusions que s’han extret d’aquests. •Ap`endix: finalment, es presenten en forma d’annexos els resultats de v`aries de les proves realitzades. 4CAP´ ITOL 1. INTRODUCCI ´ O CAP´ ITOL 2 Entorn del projecte i estat de l’art Oferim aqu´ı una introducci´o a la supercomputaci´o i als conceptes que apareixeran en aquest projecte. Aix´ı, es presenta una visi´o molt b`asica de qu`e ´es un supercomputador, dels planificadors i gestors de recursos i de les pol´ıtiques de selecci´o de recursos. 2.1 Supercomputadors Els supercomputadors s´on m`aquines pensades per a treballar amb problemes que amb un ordinador dom`estic podrien trigar mesos o fins i tot anys a poder-se resoldre. Per fer-ho, la soluci´o m´es habitual ´es connectar molts ordinadors entre s´ı, per a qu`e treballin conjuntament i aix´ı oferir m´es recursos a una aplicaci´o per a qu`e s’executi m´es r`apidament o poder executar molts al mateix temps. Cada un dels ordinadors connectats rep el nom de node; normalment tenen m´es d’un processador i disposen d’una xarxa de gran velocitat i baixa lat`encia per a les comunicacions entre les diferents tasques d’una aplicaci´o. Per poder controlar quines aplicacions s’executen en cada moment s’utilitzen sistemes de planificaci´o - batch systemsque, ajudats pels gestors de recursos, s’encarreguen de decidir en quin moment i amb quins recursos s’executa cada treball. D’aquesta manera s’optimitza el percentatge d’utilitzaci´o de la m`aquina. Per a poder-ho fer, per`o, cal que els usuaris donin una s`erie de requeriments dels seus treballs, com ara temps estimat d’execuci´o, n´umero de tasques, tasques per node, etc. D’aquesta manera el planificador t´e prou informaci´o per exercir correctament la seva tasca. 5 6CAP´ ITOL 2. ENTORN DEL PROJECTE I ESTAT DE L’ART MareNostrum MareNostrum ´es el supercomputador que s’ha utlitzat per a realitzar les proves d’aquest projecte. Est`a situat al Barcelona Supercomputing Center - Centro Nacional de Supercomputaci´on[BSC]. Disposa de 2560 nodes JS21; cada node -blade- consta de 2 processadors de 2 nuclis cada un, configurant un total de 10240 processadors, 8 GiB de mem`oria RAM i tres xarxes: una xarxa Myrinet per a les comunicacions de les aplicacions paral·leles, una xarxa Gigabit Ethernet per a l’acc´es al sistema de fitxers distribu¨ıts i una xarxa Fast Ethernet per a l’administraci´o i el manteniment del sistema. En quant a software, els nodes utilitzen un sistema operatiu GNU/Linux SLES10SP2. El planificador de treballs utilitzat ´es Moab, que es coordina amb SLURM, que realitza, ´unicament, les tasques de gestor de recursos1. Aquesta configuraci´o ofereix un rendiment m`axim te`oric de 94,21 TeraFlops, amb un rendiment sostingut de 63,83 TeraFlops segons Linpack, i una mem`oria total de 20TiB. Respecte al seu ´us per part dels usuaris, s’estableix un sistema de quotes per hores en base als projectes a desenvolupar al centre. Els diferents projectes es presenten a un comit´e independent d’experts, que en funci´o de les seves valoracions determinen l’assignaci´o de recursos a cada un dels projectes. 2.2 Gestors de recursos Els gestors de recursos s´on sistemes destinats a controlar en tot moment l’estat de totes les parts de la m`aquina. Informen al planificador de qualsevol incid`encia que pugui presentar un node i aix´ı poder-ho contemplar en planificar els treballs que t´e encuats. Podem trobar sistemes que incorporen el planificador i el gestor de recursos en una ´unica aplicaci´o, com SLURM, o sistemes en qu`e planificador i gestor de recursos s´on aplicacions independents, com ´es el cas de la combinaci´o Moab i SLURM, planificador i gestor respectivament. Amb aquesta configuraci´o, Moab ´es el sistema responsable de la planificaci´o, i cedeix la gesti´o dels treballs i les seves tasques al gestor de recursos amb el que es comunica, que passa a ser l’encarregat final de qu`e els treballs s’executin on toca i amb el nombre de tasques sol·licitades per l’usuari. Els planificadors i gestors de recursos necessiten disposar de diferents par`ametres per tal d’optimitzar l’assignaci´o de recursos de cada treball. Aquests par`ametres s´on, b`asicament, duraci´o -en horesdel treball, n´umero de nodes que requereix i n´umero de tasques per node. SLURM SLURM ´es un gestor de recursos desenvolupat al Lawrence Livermore National Laboratory (LLNL) i distribuit sota llic`encia GPL. Es basa en un sistema de plugins, el qual permet realitzar 1Com es veur`a m´es endavant, SLURM pot dur a terme les dues tasques, aix`o ´es, planificaci´o i gesti´o de recursos, de forma simult`ania 2.2. GESTORS DE RECURSOS 7 modificacions a alguna de les parts de forma relativament senzilla sense perdre cap funcionalitat. Els plugins s´on habitualment petits programes amb una interf´ıcie comuna que permeten afegir funcionalitats a altres aplicacions. En aquest cas SLURM utilitza plugins pr`acticament per a tot excepte la coordinaci´o entre els diferents plugins. Actualment, disposa tamb´e de diverses pol´ıtiques de planificaci´o, cada una implementada en un plugin diferent. Els diferents plugins d’SLURM s´on (en negreta els modificats en aquest projecte): •Accounting Storage:Plugin responsable de comunicar-se amb una base de dades per obtenir la informaci´o dels usuaris amb acc´es al sistema. •Authentication: Autentica els serveis de cada node i evita intrusions. •Checkpoint: Desa l’estat d’un treball cada cert temps, per a poder-lo recuperar en cas de fallada de hardware. •Cryptographic: Estableix com es realitzaran les comunicacions entre els diferents daemons. •Job Accounting Gather: Defineix quin sistema s’ha d’utilitzar, aix o linux, per recollir informaci´o sobre els treballs. •Job Completion: Encarregat de mantenir un registre amb tots els esdeveniments referits als treballs que es produeixen. •MPI : Defineix el tipus de xarxa mpi de qu`e es disposa, per poder executar aplicacions paral·leles. •Priority: Ens permet definir com es vol calcular la prioritat de cada treball. •Process Tracking: Estableix com s’ha de determinar a qui pertany un proc`es concret. •Scheduling: Permet definir la pol´ıtica de planificaci´o. •Resource Selection: Controla la selecci´o de recursos disponibles. •Switch: Defineix el tipus de xarxa de qu`e es disposa. •Task: Defineix si les tasques de les aplicacions has d’estar lligades a un processador en concret o no. •Topology: Defineix la topologia de xarxa per optimitzar les comunicacions. Com podem observar, SLURM disposa d’una bona quantitat de plugins, la qual cosa permet modificar gaireb´e qualsevol aspecte del seu funcionament per adaptar-lo a les nostres necessitats. SLURM utilitza tots aquests plugins per realitzar totes les tasques d’un planificador i d’un gestor de recursos. 8CAP´ ITOL 2. ENTORN DEL PROJECTE I ESTAT DE L’ART Est`a dividit en un controlador (slurmctld) i un daemon a cada node (slurmd), que s´on els encarregats de comunicar al controlador quin ´es l’estat d’un node i de controlar l’estat del treballs en el seu node, El controlador, per la seva part, s’encarrega de processar totes les peticions dels usuaris, planificar els treballs i mantenir un registre del qu`e succeix en tot moment. Aix´ı doncs, gaireb´e tota la feina la realitza el controlador, ja que els slurmd s´on programes dissenyats per a reduir al m´ınim la seva c`arrega en cada node. Figura 2.1: Diagrama de les fases d’un treball des de que l’usuari l’envia fins que comen¸ca a executar-se. Les fases per les qu`e passa un treball des de que un usuari realitza la petici´o d’encuar-lo fins que aquest comen¸ca a executar-se s´on, de manera molt simplificada, les seg¨uents:(fig.2.1) Primer, un usuari envia un treball mitjan¸cant la comanda sbatch. Aquesta es comunica amb l’slurmctld, que rep la petici´o d’un nou treball, la processa i comprova que la petici´o sigui correcta. Despr´es, el nou treball passa al plugin de planificaci´o que l’afegeix a la cua, i pregunta al plugin de selecci´o de recursos si es pot executar immediatament. En cas afirmatiu, demana una assignaci´o de recursos, i sol·licita a slurmctld l’execuci´o. Si no es pot executar en aquest moment, sol·licita una estimaci´o al plugin de selecci´o de recursos i la desa. Cada vegada que finalitzi un treball o cada cert temps, el plugin de planificaci´o comprovar`a si el primer treball en cua es pot executar. 2.3 Less Consume Less Consume ´es un pol´ıtica de selecci´o de recursos desenvolupada al BSC per en Francesc Guim, tema de recerca de la seva tesi doctoral, que no ha estat mai implementada en un entorn real. Est`a basada en la pol´ıtica FirstFit, que selecciona els recursos que permeten executar un treball el m´es aviat possible, afegint una nova restricci´o: la penalitzaci´o resultant de l’´us d’ample de banda a mem`oria ha de ser el m´ınim possible, ´es a dir, el treball s’ha de veure afectat el m´ınim possible per compartir l’ample de banda amb cap altre treball o amb ell mateix. La penalitzaci´o ´es el m`axim de la penalitzaci´o dels nodes de l’assignaci´o, i aquesta ´es proporcional a la saturaci´o de l’ample de banda de mem`oria. L’objectiu de la pol´ıtica ´es doncs, a partir d’una assignaci´o inicial de refer`encia, obtenir l’assignaci´o amb la penalitzaci´o m´ınima possible 2.3. LESS CONSUME 9 sense augmentar el temps d’inici del treball. La pol´ıtica utilitza un taula de reserva per mantenir en tot moment un registre de quins recursos s’han assignat a cadascun dels treballs. En aquest cas, els recursos s´on els processadors i el temps. Per tant, donada la taula de reserva, la descripci´o d’un treball (n´umero de cpus, duraci´o,...) i un temps d’inici (treq), Less Consume troba l’assignaci´o que minimitza la penalitzaci´o d’un treball. Per fer-ho segueix els seg¨uents passos: 1. Per cada processador de la taula de reserva es selecciona l’interval de temps m´es proper atreq que el satisfaci: el processador no est`a assignat durant aquest interval de temps i, la duraci´o de l’interval ´es superior o igual a la duraci´o requerida pel treball. Cadascun d’aquests intervals de temps associats a un processador(Buckets) s’afegeixen a una llista ordenada segons el seu temps d’inici. 2. D’aquest conjunt de Buckets, es seleccionen els n (n=cpus) primers que satisfacin que el seu interval de temps comparteixi almenys el temps requerit pel treball. 3. En cas que en el pas anterior el n´umero de Buckets sigui inferior al n´umero sol·licitat de cpus, implica que no hi havia suficients buckets que compartissin el temps necessari. En aquesta situaci´o, es selecciona el primer bucket amb un temps d’inici (ti0) superior a treq i s’actualitza treq amb treq =ti0, i es tornen a iterar els passos 1, 2 i 3. En aquest punt, disposem de tres conjunts de buckets: •Els buckets descartats per qu`e mai formaran part d’una assignaci´o v`alida. •Els buckets seleccionats en aquest punt, i que satifan els requisits del treball. En cas que la penalitzaci´o no es pugui disminuir amb una futura selecci´o, aquest ser`a el conjunt de buckets seleccionats per l’assignaci´o. •Els buckets que encara no han estat evaluats. Aquests s´on els que s’utilitzaran per intentar millorar l’assignaci´o inicial, intentant reduir al m`axim la penalitzaci´o. 4. Per cadascun dels buckets seleccionats, l’algoritme calcula la penalitzaci´o associada en cas de qu`e aquest bucket s’assign´es al treball. Si tots els buckets tenen una penalitzaci´o de 1, aquesta ´es l’assignaci´o `optima i l’algorisme acabaria aqui. 5. Per cada bucket en el conjunt per evaluar: (a) Si el nombre de buckets al conjunt dels seleccionats ´es inferior als processadors sol·licitats, s’afegeix el bucket actual al conjunt de seleccionats i es continua amb la seg¨uent iteraci´o. (b) De manera semblant al pas anterior, es calcula la penalitzaci´o que provocaria la selecci´o d’aquest bucket. 16 CAP´ ITOL 3. DESENVOLUPAMENT DEL PROJECTE obtat per a implementar-lo per cada treball tot i que l’avaluaci´o des realitzar`a de forma general. Un exemple de l’´us d’sbatch ´es el seg¨uent: sbatch -n2 -N2 --mem-bandwidth=2000 --lc-threshold=1.5 exec2.sh En aquest exemple es defineix un treball que executar`a l’script exec2.sh utilitzant dues tasques en dos nodes amb un ample de banda de 2000MB/s per tasca i una penalitzaci´o m`axima de 1,5. Per a qu`e la comanda sbatch reconegui els dos nous par`ametres, s’ha modificat el mecanisme per a la lectura de par`ametres, l’estructura que els emmagatzema per despr´es enviar-los al controlador i el mecanisme de comunicaci´o entre sbatch i el controlador per tal d’enviar els nous par`ametres. Per la part del controlador s’ha modificat l’estructura job record, que cont´e tota la informaci´o referent a un treball: el n´umero de tasques, n´umero de cpus, la prioritat, etc., afegint-hi tres nous camps: •mem bandwidth: emmagatzema el requisit d’ample de banda de mem`oria del treball. •lc threshold: emmagatzema el llindar m`axim perm`es de penalitzaci´o. •penalty: emmagatzema la penalitzaci´o del treball. 3.3 Implementaci´o d’una primera versi´o Per implementar la pol´ıtica Less Consume Threshold, s’ha decidit utilitzar com a punt de partida un plugin ja existent, i no crear-ne un des de zero. S’ha pres aquesta decisi´o per no perdre funcionalitats, que els plugins actuals ja ofereixen, i perqu`e afegir el control d’ample de banda en els plugins actuals era, a priori, l’opci´o m´es senzilla. SLURM defineix un conjunt de funcions que han d’apar`eixer sempre en el plugin, i que seran les ´uniques que s’utilitzaran des de fora del mateix. La figura 3.1 mostra la llista de funcions m´es rellevants del plugin i marcades aquelles que s’han modificat. La funci´o principal ´es select p job test, encarregada de realitzar la selecci´o de recursos per a un treball o, depenent del mode en qu`e es crida, de comprovar si el treball ser`a capa¸c d’executarse en algun moment. int select_p_job_test (struct job_record *job_ptr, bitstr_t *bitmap, int min_nodes, int max_nodes, int req_nodes, int mode); Aquesta funci´o rep per par`ametre l’estructura que descriu el treball (job ptr), un bitmap amb els possibles nodes a utilitzar, dels quals es seleccionaran el nodes a assignar(bitmap), el n´umero m´ınim de nodes(min nodes), el n´umero m`axim de nodes(max nodes), el n´umero de nodes sol·licitats pel treball(req nodes) i el mode en qu`e s’ha d’executar la funci´o(mode), que pot ser: 3.3. IMPLEMENTACI ´ O D’UNA PRIMERA VERSI ´ O17 #Funcions de la API _add_job_to_res _rm_job_from_res init fini select_p_node_init select_p_job_test #Funcions auxiliars _can_job_run_on_node _verify_node_state _get_res_usage _choose_nodes _select_nodes cr_job_test _will_run_test _dup_node_usage #Funcions auxiliars afegides _list_find_job_id_lc recalculate_job_penalty Figura 3.1: Llista de les funcions m´es importants del plugin de selecci´o de recursos •SELECT MODE RUN NOW: intenta planificar el treball en el moment present. •SELECT MODE TEST ONLY: prova si el treball podr`a executar-se. •SELECT MODE WILL RUN: determina quan i on podr`a executar-se el treball. Aquesta funci´o, depenent amb quin mode hagi estat cridada, crida a will run test, en el cas de qu`e s’utilitzi el mode SELECT MODE WILL RUN o a cr job test amb qualsevol dels altres dos modes. La funci´o will run test s’encarrega d’anar cridant a cr job test, i verificar si el treball es pot executar. Si no es pot executar, simula l’eliminaci´o de l’assignaci´o del primer treball en acabar i torna a comprovar si aleshores el treball es podr`a executar. Es va repetint l’ultima operaci´o fins que el treball es pot executar, i es marca com a temps estimat de comen¸cament la finalitzaci´o de l’ultim treball eliminat. La funci´o cr job test ´es la funci´o que realitza gaireb´e tota la feina de select p job test. Segons es pot extreure de la documentaci´o d’SLURM el procediment es pot dividir en tres passos: •Comparar els nodes en el bitmap avail amb l’estat actual de cadascun d’aquests nodes, per tal de trobar els nodes disponibles que satisfacin els requisits del treball. •Comprovar els nodes del bitmap avail amb recursos assignats. •Seleccionar l’´us de recursos, dels restants al bitmap avail, per aquest treball, amb el posicionament influenciat per les assignacions existents. 18 CAP´ ITOL 3. DESENVOLUPAMENT DEL PROJECTE I l’´ultim d’aquests en: * Pas 1: Cerca nodes lliures en totes les particions. Si n’hi ha * d´ona una assignaci´o al treball i surt. Si no continua. * * Pas 2: Elimina els recursos que s’estan utilitzan actualment * per particions de major prioritat, i avalua si el treball * encara es pot executar. Si no surt. * * Pas 3: Cerca nodes lliures en les particions amb la mateixa * prioritat que la partici´o del treball. Si n’hi ha aleshores * ves al pas 6. Si no continua: * * Pas 4: Cerca una allocataci´o dins de la partici´o del treball. * Si no es troba cap assignaci´o possible surt. Si no * continua: * * Pas 5: Assigna el treball i surt * * Pas 6: Assigna el treball i surt(Algoritme diferent del pas 5) Per a realitzar tots aquests passos cr job test utilitza les funcions de la figura 3.2. De totes aquestes funcions, les que s’han modificat per a poder implementar la primera versi´o han estat: •cr job test (veure explicaci´o anterior) •verify node state, determina si un node es pot utilitzar pel treball que s’est`a avaluant. •can job run on node, determina quins recursos d’un node concret poden assignar-se al treball avaluat. La funci´o cr job test s’ha modificat per a desar l’ample de banda de mem`oria que s’ha assignat al treball en cada node. Per fer-ho, s’ha afegit a l’estructura select job res, que defineix exactament quins recursos s’han assignat al treball,un camp per emmagatzemar l’ample de banda de mem`oria que s’ha assignat al treball a cada un dels node assignats per a la seva execuci´o. La funci´o verify node state s’ha modificat afegint el control de l’ample de banda de mem`oria, per comprovar si el node en disposa de prou, per tal de descartar-lo en cas que no sigui aix´ı. Respecte el fragment de codi afegit veure Fig. 3.3. La funci´o can job run on node (veure Fig. 3.4) s’ha modificat per tenir en compte l’ample de banda de mem`oria en l’assignaci´o de recursos. Aix´ı doncs, s’assignen els recursos segons 3.4. IMPLEMENTACI ´ O DE MILLORES 19 Figura 3.2: Diagrama de les fases d’un treball des de que l’usuari l’envia fins que comen¸ca a executar-se. l’ample de banda disponible. Si un node disposa de 3000MB/s i un treball demana 1000MB/s, s’assignaran 3 tasques del treball a aquest node, ja que assignar-ne una m´es provocaria una sobrec`arrega dels recursos. Aquesta primera versi´o permetia assignar els recursos segons l’ample de banda de mem`oria, per`o sense tenir en compte si els treballs havien sol·licitat una penalitzaci´o m`axima (provocant una penalitzaci´o m`axima de 1 per aquest fet). Aquest fet comportava que no es pogu´essin produir mai penalitzacions per la compartici´o de recursos, ja que no es podia assignar una cpu lliure d’un node ja ocupat per un treball si l’´us total d’ample de banda de mem`oria superava el disponible en el node. 3.4 Implementaci´o de millores Un cop avaluada i comprovat el seu correcte funcionament, aquesta primera versi´o es modifica per contemplar el par`ametre de llindar m`axim de penalitzaci´o i els par`ametres de configuraci´o per modificar el comportament del plugin. 3.4.1 Par`ametre del llindar m`axim de penalitzaci´o Per implementar el par`ametre del llindar m`axim de penalitzaci´o nom´es s’ha modificat la funci´o can job run on node; aquesta implementaci´o, per`o, ha suposat la reestructuraci´o completa del fragment exposat anteriorment(Veure Sec 3.4.2). Amb aquest nou par`ametre, la funci´o determina quantes cpus de cada node es poden assignar a un treball tenint en consideraci´o 20 CAP´ ITOL 3. DESENVOLUPAMENT DEL PROJECTE /∗ ∗Check i f ther e i s enough memory bandwidth at the node ∗/ i f ( job_ptr -> details -> mem_bandwidth ){ free_bandwidth = select_node_record [i]. mem_bandwidth ; i f ( free_bandwidth * job_ptr -> details -> lc_threshold < min_bandwidth ) { debug3(" less_consume : _vns: node %s no bandwidth %u < %u", select_node_record [i]. node_ptr ->name , free_bandwidth , min_bandwidth ); goto clear_bit ; } } Figura 3.3: Fragment de codi afegit a verify node state per a controlar l’ample de banda de mem`oria disponible req_mem_bandwidth = job_ptr -> details -> mem_bandwidth ; avail_mem_bandwidth = select_node_record [ node_i ]. mem_bandwidth ; i f (! test_only ) avail_mem_bandwidth -= node_usage[node_i].alloc_mem_bandwidth; /∗memory bandwidth reques te d i s per ta sk ∗/ while ( cpus > 0 ( req_m em_b andwidth * cpus ) > a vail_mem_ba ndwid th ) cpus --; i f ( cpus < job_ptr -> details -> ntasks_per_node ){ cpus = 0; bit_nclear ( core_map , cr_get_coremap_offset ( node_i ) ,( cr_get_coremap_offset ( node_i +1) ) -1); } Figura 3.4: Fragment de codi afegit a can job run on node per a controlar l’ample de banda de mem`oria disponible 3.4. IMPLEMENTACI ´ O DE MILLORES 21 els possibles treballs existents en aquest node. Aquesta modificaci´o, per`o, no ´es suficient at`es que entre treballs no apareixer`a mai penalitzaci´o, ja que en la primera versi´o no es permet augmentar la penalitzaci´o d’un treball ja existent en el node. 3.4.2 Nous par`ametres de configuraci´o Per aquest motiu, s’han afegit nous par`ametres de configuraci´o. Aquests modifiquen el comportament del plugin per permetre l’augment de la penalitzaci´o d’un treball fins al seu llindar i per augmentar el temps d’execuci´o requerit en funci´o del llindar. Els possibles valors es recullen al par`ametre SelectTypeParameters i s´on: LC MEMORY , indica que el plugin ha de mantenir el seu comportament per defecte. LC PENALTY , que modifica el comportament permetent augmentar la penalitzaci´o dels treballs existents en un node fins al seu llindar. LC REQ TIME , que permet augmentar el temps d’execuci´o requerit pel treball. LC PENALTY REQ TIME , combinaci´o dels dos par`ametres anteriors. Per a qu`e aquests par`ametres de configuraci´o estiguin disponibles, tan sols s’han hagut d’afegir a l’estructura select type plugin info que descriu tots els possibles par`ametres dels plugins de selecci´o de recursos. Un cop s’ha disposat d’aquests nous par`ametres, s’ha modificat el codi per a tenir-los en compte, i modificar el comportament segons quin hagi estat seleccionat. Aquests canvis afecten principalment la funci´o can job run on node (veure Fig 3.5) ja que, tal i com s’ha comentat pr`eviament, s’ha hagut de reestructurar tot el fragment vist anteriorment(veure Fig 3.4). D’aquesta manera, el codi queda dividit en dues parts segons el mode en qu`e s’hagi cridat a la funci´o (test only, normal). En el cas de test only, mode en el qu`e es comprova si un treball podr`a executar-se mai en aquest node, nom´es es t´e en compte el propi treball i no altres treballs que pugin estar executant-se en aquest moment en el node avaluat. En aquest mode no es pot saber quin ser`a l’estat del node un cop el treball comenci a executar-se. En el mode normal s´ı que es tenen en compte els treballs que puguin estar executant-se en el node, ja que en aquest mode es busca una assignaci´o pel treball. Primer es calcula l’ample de banda utilitzat en cas de fer servir tots els processadors lliures del node. Posteriorment es calcula la penalitzaci´o i, si aquesta ´es superior al llindar establert, es va reduint el nombre de cpus assignades i recalculant la penalitzaci´o fins que aquesta ´es inferior al llindar o fins que no queden cpus. Un cop establert el nombre final de cpus que es poden assignar, si l’ample de banda utilitzat ´es superior al disponible del node, es comprova si aquesta assignaci´o afecta a l’execuci´o dels altres treballs executant-se al node. En el cas de qu`e hi hagi treballs executant-se, per cada un d’ells es comprova si s’est`a augmentant la seva penalitzaci´o. Si ´es aix´ı, l’acci´o dependr`a aleshores del par`ametre SelectTypeParameters; si est`a establert en un dels valors que permeten augmentar la penalitzaci´o dels treballs existents, aleshores es 22 CAP´ ITOL 3. DESENVOLUPAMENT DEL PROJECTE req_mem_bandwidth = job_ptr -> mem_bandwidth ; avail_mem_bandwidth = select_node_record [ node_i ]. mem_bandwidth ; threshold = job_ptr -> lc_threshold ; i f ( test_only ){ alloc_mem_bandwidth = req_mem_bandwidth * cpus ; new_penalty = (double)alloc_mem_bandwidth / avail_mem_bandwidth; while (cpus > 0 new_penalty > threshold ){ cpus --; alloc_mem_bandwidth = req_mem_bandwidth * cpus ; new_penalty = (double)alloc_mem_bandwidth / avail_mem_bandwidth; } }else{ alloc_mem_bandwidth = node_usage[node_i].alloc_mem_bandwidth + req_mem_ band width * cpus ; /∗memory r eq ue sted i s per t as k ∗/ alloc_mem_bandwidth = node_usage[node_i].alloc_mem_bandwidth + req_mem_ band width * cpus ; new_penalty = (double)alloc_mem_bandwidth / avail_mem_bandwidth; while (cpus > 0 new_penalty > threshold ){ cpus --; alloc_mem_bandwidth = node_usage[node_i].alloc_mem_bandwidth + req_mem_ band width * cpus ; new_penalty = (double)alloc_mem_bandwidth / avail_mem_bandwidth; } alloc_mem_bandwidth = node_usage[node_i].alloc_mem_bandwidth + req_mem_ band width * cpus ; i f (alloc_mem_bandwidth > avail_mem_bandwidth){ new_penalty = alloc_mem_bandwidth / avail_mem_bandwidth; job_iterator = list_iterator_create ( node_usage [ node_i ]. job_list ); while(node_job_ptr = (struct job_record *) list_next ( job_iterator )){ i f ( cr_type == LC_PENALTY || cr_type == LC_REQ_TIME_PENALTY ){ i f ( new_penalty > node_job_ptr -> lc_threshold ) cpus = 0; }el se i f ( new_penalty > node_job_ptr -> penalty ) cpus = 0; } } } Figura 3.5: Modificaci´o de la funci´o can job run on node per a tenir en compte els nous par`ametres 3.5. MODIFICACI ´ O DEL PLUGIN D’ACCOUNTING 23 struct node_use_record { uint16_t node_state ; /∗se e n o d e c r s t a t e comments ∗/ uint32_t alloc_memory; /∗r e a l memory r es erved by already ∗scheduled jobs ∗/ uint32_t alloc_mem_bandwidth; /∗a l l o c a t e d memory bandwidth ∗/ List job_list ; /∗l i s t of running jo b s ∗/ }; Figura 3.6: Estructura node use record amb els dos nous camps comprova que la nova penalitzaci´o no sigui superior al llindar de cada un dels treballs. Si ´es superior no es pot assignar cap cpu. Si, en canvi, el par`ametre no ens permet augmentar la penalitzaci´o, es comprova que la penalitzaci´o dels treballs sigui menor a l’obtinguda en aquest node, i si no ´es aix´ı tampoc s’assigna cap cpu. Per poder con`eixer quins s´on els treballs existents en un node, s’ha afegit una llista dels treballs executant-se en un node, a l’estructura node use record(veure Fig. 3.6), que cont´e la informaci´o dels recursos assignats d’un node. Un treball s’afegeix a aquesta llista, dins de la funci´o add job to res. Aquesta ´es la funci´o que s’executa just abans que un treball comenci el proc´es d’execuci´o, i per tant ´es tamb´e aqu´ı on s’actualitzen els valors de l’estructura node use - record amb el nou consum, i es recalcula la penalitzaci´o de cada un dels treballs amb els qu`e el treball apunt de comen¸car compartir`a node. En el cas que s’hagi seleccionat un par`ametre del plugin que permeti augmentar el temps requerit d’un treball, tamb´e ´es en aquesta funci´o on s’incrementa, i s’incrementa segons el llindar establert pel treball, ja que, encara que en el moment de comen¸car a executar-se no tingui penalitzaci´o, ´es possible que en un futur la tingui, i per tant el m´es segur ´es augmentar la penalitzaci´o just en el moment de l’inici de l’execuci´o. De la mateixa manera que s’afegeix un treball a la llista de treballs d’un node, tamb´e s’elimina d’aquesta llista quan el treball acaba. Aquesta tasca es du a terme a la funci´o rm job from res, que de la mateixa manera que add job to res, tamb´e actualitza els valors de node use record, per`o en aquest cas reduint els recursos segons els consum del treball que s’elimina. 3.5 Modificaci´o del plugin d’accounting El plugin d’accounting Job Completion, ´es l’encarregat d’escriure en un arxiu las dades d’un treball un cop aquest finalitza. El format per defecte, per`o, no ´es suficient per a poder obtenir una informaci´o detallada de l’execuci´o d’un treball, doncs no ofereix informaci´o sobre l’ample de banda utilitzat pel treball ni en quins processadors s’ha executat. JobId=21065 UserId=fenoy(100) GroupId=Users(100) Name=test JobState=COMPLETED Partition=projects TimeLimit=22 StartTime=2009-06-04T18:36:14 EndTime=2009-06-04T18:36:24 NodeList=cabezatest NodeCnt=1 ProcCnt=1 WorkDir=/home/user Per tal de poder analitzar el comportament del plugin de selecci´o de recursos es necessita 24 CAP´ ITOL 3. DESENVOLUPAMENT DEL PROJECTE informaci´o m´es detallada, que descrigui apart de la informaci´o vista anteriorment, l’ample de banda de mem`oria, la penalitzaci´o, el llindar i el temps d’enviament del treball. Per a ferho s’ha modificat el plugin de Job Completion, per qu`e mostri tota aquesta informaci´o en un format est`andard, tal i com s’ha vist anteriorment(Secci´o 2.4). Aquest format, per`o, no inclou la informaci´o exclusiva de la pol´ıtica Less Consume, com l’ample de banda requerit per un treball, o la penalitzaci´o a la que aquest s’ha vist sotm`es. La informaci´o que s’ha afegit al format ´es: •ample de banda de mem`oria requerit per un treball. •llindar m`axim de penalitzaci´o perm`es durant la execuci´o. •penalitzaci´o m`axima a la que el treball s’ha vist sotm`es. •Temps requerit original. •Un n´umero indicant l’assignaci´o de processadors. •Una cadena de zeros i uns indicant l’assignaci´o de processadors. Aix´ı doncs, el format final queda com l’original amb els sis nous camps afegits al final. 35 1275411912 31576 1273 8 -1 -1 8 24 0 COMPLETED bsc99368 bsc99 script\_34.cmd -1 -1 -1 -1 1660 1.100000 1.000000 22 286331153 00010001000100010001000100010001 CAP´ ITOL 4 Avaluaci´o i an`alisi de resultats Un cop descrit el desenvolupament del projecte, aquest cap´ıtol es centra en la preparaci´o i execuci´o de les proves i en l’an`alisi dels seus resultats. 4.1 Entorns de treball Per cada fase del projecte s’ha utilitzat un entorn de proves i de treball diferent, segons les necessitats. S’exposa a continuaci´o una breu ressenya dels entorns de treball utilitzats, la seva descripci´o i per a qu`e s’ha utilitzat. 4.1.1 Desenvolupament: Ordinador personal Durant l’etapa de desenvolupament del projecte s’ha utilitzat un ordinador personal. Es tracta d’un ordinador de sobretaula amb un processador AMD X2 amb doble nucli. Aquest ha estat la base per a tot el desenvolupament i el que s’ha utilitzat com a punt de connexi´o a les diverses m`aquines on s’ha realitzat l’an`alisi. Aquest ordinador ha estat, tamb´e, la plataforma de desenvolupament dels dos plugins d’SLURM, i de la validaci´o del correcte funcionament. Per realitzar aquesta validaci´o, s’ha instal·lat SLURM amb el par`ametre de configuraci´o –enablemultiple-slurmd, que permet executar varis daemons slurmd, per simular un cl´uster m´es gran que el propi ordinador. D’aquesta manera, s’han configurat 5 nodes, per poder comprovar tant el funcionament correcte del plugin de selecci´o de recursos com del plugin d’accounting. Del primer s’ha pogut comprovar l’assignaci´o correcta dels recursos segons l’ample de banda de mem`oria disponible, mentre que del segon s’ha comprovat, apart de qu`e aparegu´es tota la informaci´o 25 32 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS #type tasks niters time mem_bandwidth appname h 8 10 1429 1600 cg .D.8 h 8 100 12800 1660 cg .D.8 h 16 10 411 1500 cg.D.16 h 32 10 251 1440 cg.D.32 h 1 60 1200 1935 sintetichigh h 2 60 1200 1935 sintetichigh h 2 2 41 1935 sintetichigh h 4 60 1200 1935 sintetichigh m 4 40 132 800 cg .C.4 m 16 10 411 800 cg.C .16 m 1 60 1200 1050 sinteticmed m 2 60 1200 1050 sinteticmed m 2 2 41 1050 sinteticmed m 4 60 1200 1050 sinteticmed l 2 200 328 570 cg.B.2 l 4 200 200 580 cg.B.4 l 8 200 107 445 cg.B.8 l 16 400 346 480 sp.C .16 l 1 60 1200 83 sinteticlow l 2 60 1200 83 sinteticlow l 8 2 41 83 sinteticlow l 4 60 1200 83 sinteticlow Figura 4.6: Arxiu d’aplicacions utilitzat per a la generaci´o dels workloads que ´es: •h: Alt consum d’ample de banda de mem`oria >1400MB/s •m: Mig consum d’ample de banda de mem`oria ≃900MB/s •l: Baix consum d’ample de banda de mem`oria <600MB/s Tamb´e cont´e el n´umero de tasques de l’aplicaci´o, el n´umero d’iteracions amb les que s’ha executat, el temps que ha durat l’execuci´o, l’ample de banda de mem`oria que ha consumit i el nom de l’aplicaci´o. Amb aquests par`ametres i unes petites f`ormules per calcular el nombre d’iteracions que cal executar, s’assigna una aplicaci´o a cada un dels treballs descrits al workload base, intentant mantenir al m`axim el temps marcat. La sortida de l’script ´es, per una part, un resum del workload (Veure Fig 4.7) i per un altra l’script que s’ha de desar en un fitxer(submitter.pl) per a poder-lo executar un cop s’ha iniciat SLURM(Veure Fig. 4.8). La figura 4.7 mostra les primeres l´ınies del resum del workload. Les primeres l´ınies corresponen a l’encap¸calament i descriuen amb quins par`ametres s’ha executat l’script que genera els workloads. Les files HIGH,MEDIUM iLOW corresponen al nombre de treballs que hi ha de cada tipus. A partir d’aqu´ı comen¸ca la descripci´o del treballs. Per cada un d’ells s’observa el temps en qu`e s’ha de llan¸car el treball, el temps sol·licitat d’execuci´o, el nombre de tasques, l’aplicaci´o que executar`a, el nombre d’iteracions que realitzar`a i l’ample de banda que consumeix aquesta aplicaci´o. Pel qu`e fa a l’script submitter.pl(Veure Fig. 4.8, cada treball consta de dues l´ınies. La 4.5. EXECUCI ´ O DE LES PROVES 33 High : 80 Medium: 10 Low: 10 File : workload . txt HIGH : 44 MEDIUM: 3 LOW: 3 18 43 43 4 mg .C.4 3 88 46 267 267 2 sintetichigh 16 1935 233 368 368 4 sintetichigh 22 1935 271 4862 4862 8 cg .D.8 34 1600 322 83 83 1 sintetichigh 5 1935 369 167 167 2 sintetichigh 10 1935 573 83 83 4 sintetichigh 5 1935 620 323 323 4 cg.C.4 98 800 668 173 173 4 mg.C.4 12 88 855 924 924 8 mg.C.8 528 440 Figura 4.7: Fragment del resum del workload generat primera correspon a l’espera per a llan¸car el treball. El workload base defineix en quin moment s’ha d’enviar un treball a la cua, i per tant aqu´ı s’ha de realitzar una espera abans de poder-lo enviar. La segona l´ınia correspon a l’execuci´o de la comanda sbatch amb tots el par`ametres necessaris per a la correcta execuci´o de l’aplicaci´o. Els par`ametres que s’utilitzen s´on: •-n: nombre de tasques •--time: temps requerit d’execuci´o •--mem-bandwidth: ample de banda de mem`oria que requereix aquesta aplicaci´o •--lc-threshold: llindar m`axim perm`es de penalitzaci´o La comanda sbatch no pot executar una aplicaci´o, sin´o que ha d’executar un script. ´ Es per aix`o que l’ultim par`ametre que apareix a la l´ınia d’execuci´o d’sbatch ´es la crida a una funci´o(gen - script). Aquesta funci´o crea l’script que es llan¸car`a a cues, i retorna el nom d’aquest script. 4.5 Execuci´o de les proves Per analitzar el funcionament del plugin s’han utilitzat tres escenaris diferents, segons l’ample de banda de mem`oria consumit per la majoria d’aplicacions. •HIGH: La majoria d’aplicacions (80%) tenen una gran demanda d’ample de banda de mem`oria. •MEDIUM: Aproximadament la meitat (50%) de les aplicacions tenen uns requisits elevats d’ample de banda de mem`oria 34 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS sleep 18; system(" sbatch -n4 --time =00:43 --mem - bandwidth =88 --lc - threshold =1.1 ". gen \ _script ("mg.C.4.3 ")); sleep 28; system(" sbatch -n2 --time =04:27 --mem - bandwidth =1935 --lc - threshold =1.1 ". gen \ _script ("sintetichigh.16")); sleep 187; system(" sbatch -n4 --time =06:08 --mem - bandwidth =1935 --lc - threshold =1.1 ". gen \ _script ("sintetichigh.22")); sleep 38; system(" sbatch -n8 --time =01:21:02 --mem - bandwidth =1600 --lc - threshold =1.1 ". gen \ _script (" cg .D .8.34 ")); sleep 51; system(" sbatch -n1 --time =01:23 --mem - bandwidth =1935 --lc - threshold =1.1 ". gen \ _script ("sintetichigh.5")); Figura 4.8: Fragment de l’script submitter.pl •LOW: Poques aplicacions (10%) tenen un alt consum d’ample de banda de mem`oria A partir d’aquests escenaris, s’han generat 3 workloads, un per a cada escenari, i s’han realitzat 6 execucions de cada un d’ells, variant el plugin de selecci´o de recursos o els par`ametres d’aquest. S’ha utilitzat el plugin original (Consumable Resources) i el plugin desenvolupat en aquest projecte, tenint sempre activat el par`ametre que permet augmentar el temps requerit per un treball. Les variacions doncs venen donades per l’activaci´o o no del par`ametre que permet augmentar la penalitzaci´o, i del valor del llindar m`axim de penalitzaci´o d’un treball. S’han descartat les combinacions amb la opci´o d’augmentar el temps sol·licitat per un treball per qu`e aquest fet provocaria que es matessin molts treballs per excedir el temps sol·licitat. Les combinacions s´on les seg¨uents: Threshold REQ TIME PENALTY Consumable Resources - - Less Consume 1 X - Less Consume 1.1 X - Less Consume 1.1 X X Less Consume 1.2 X - Less Consume 1.2 X X Taula 4.1: Escenaris de les diverses proves realitzades 4.6 Avaluaci´o dels resultats A continuaci´o s’analitzen els resultats de les execucions dels workloads en els diferents escenaris. En primer lloc es realitza un an`alisi entre les diverses execucions d’un mateix workload per comparar les difer`encies entre les diferents pol´ıtiques i, posteriorment, un an`alisi global del 4.6. AVALUACI ´ O DELS RESULTATS 35 comportament del plugin. Les m`etriques utilitzades estan dissenyades per a validar els seg¨uents comportaments: L’augment del llindar m`axim perm`es de penalitzaci´o ha de comportar una reducci´o en el temps d’espera dels treballs, un augment en la penalitzaci´o en el temps d’execuci´o, un increment en la utilitzaci´o i la saturaci´o del sistema. Per fer refer`encia a les diferents configuracions del workloads, en totes les imatges s’utilitzen abreviatures; en primer lloc el tipus de pol´ıtica de selecci´o de recursos, CR (Consumable Resources) o LC (Less Consume). A continuaci´o, en els casos en que s’utilitzi un llindar, apareix el valor d’aquest (1.1 `o 1.2) i, finalment, apareix quin par`ametre de configuraci´o s’ha utilitzat durant l’execuci´o; LC REQ - TIME (R) o LC REQ TIME PENALTY(RP). Tamb´e cal mencionar que, en les execucions s’ha configurat SLURM per a qu`e permeti un cert temps extra d’execuci´o de cada treball. Aquest temps, configurat a partir del par`ametre OverTimeLimit, ´es de 5 minuts, ja que ´es un valor acceptable i que permet que, en el cas de qu`e a un treball li resti molt poc temps per finalitzar, tot el temps que s’ha executat no es perdi. La pol´ıtica de planificaci´o que s’utilitza en les proves ´es la de backfilling que inclou SLURM. 4.6.1 M`etriques utilitzades Per a la realitzaci´o de l’an`alisi de les diferents execucions dels workloads en els diferents escenaris s’han creat una s`erie de gr`afiques per poder visualitzar d’una manera m´es c`omoda la gran quantitat d’informaci´o de qu`e es disposa i, d’aquesta manera centrar l’an`alisi cada vegada en un aspecte concret del funcionament. S’utilitzen les m`etriques num`eriques i an`alisis visuals seg¨uents: Estat de les Aplicacions (gr`afica paraver) Aquest ´es l’an`alisi visual m´es general. La imatge extreta amb l’aplicaci´o Paraver[Par], una eina desenvolupada al BSC-CNS, permet visualitzar per cada una de les execucions d’un workload en quin estat es troba cada aplicaci´o. L’eix x mostra el temps i l’eix y les diferents aplicacions del workload. Aix´ı doncs, es disposa d’una l´ınia per a cada aplicaci´o que ens mostra la seva evoluci´o. Aquestes m`etriques estan normalitzades al temps d’execuci´o m´es llarg, per tal de poder observar f`acilment la duraci´o relativa entre les diferents execucions. S’observa el temps d’espera de cada treball, el temps d’execuci´o i el temps total del workload. Una aplicaci´o pot tenir 3 estats diferents, cada un representat amb un color diferent: •Waiting: Aquest ´es l’estat en el qu`e entra un treball al sistema. Es mostra en color vermell i pot no apar`eixer si el treball comen¸ca a executar-se des del moment en el qu`e s’envia al sistema de cues. •Running: El treball es troba en aquest estat mentre s’est`a executant. Es mostra en color blau. 36 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS •Completed: Un cop ha finalitzat l’aplicaci´o, pot apar`eixer un espai en blanc que simbolitza el temps de m´es que ha sol·licitat el treball, ´es a dir, el temps que li ha sobrat respecte al demanat. Un cop passat aquest temps, la resta de la l´ınia es mostra en negre. ´ Us de l’ample de banda de cada node(gr`afica paraver) Aquesta imatge mostra l’ample de banda assignat per treballs a cada node. ´ Es la suma de l’ample de banda requerit per les tasques que s’estan executant en el node. L’eix x representa el temps i l’eix y s´on els nodes del sistema, tenint aix´ı una l´ınia per a cada node. Els valors de l’ample de banda es mostren com un gradient de colors que van del verd al blau, de menys ample de banda de mem`oria a m´es respectivament. El color taronja indica que un node t´e m´es ample de banda assignat del que disposa, i per tant hi haur`a penalitzaci´o en els treballs que s’executen en aquest node. Qualsevol valor que superi els 3GiB/s es mostra en color taronja. El color negre indica un valor de 0 i, per tant, que no hi ha cap treball executant-se en aquest node. Ample de banda del sistema Aquesta m`etrica ´es un gr`afic de l’ample de banda de mem`oria assignat a tot el sistema. ´ Es la suma de l’ample de banda de mem`oria assignat a cada node en cada moment. L’eix x representa el temps i l’eix y la quantitat d’ample de banda de mem`oria assignat. Es presenten dues l´ınies, una de color vermell que representa l’ample de banda en el cas de l’execuci´o del workload amb CR i una l´ınia de color blau que representa l’ample de banda de mem`oria de l’execuci´o amb LC1.2RP. S’han escollit aquestes dues configuracions perqu`e s´on les que m´es saturaci´o provoquen en els nodes. Aquesta m`etrica permet obtenir una quantificaci´o de la saturaci´o del sistema que amb l’anterior imatge no es pot extreure, ja que el color taronja no ens indica quant ample de banda per sobre del l´ımit del node est`a assignat. Slowdown mig del temps d’execuci´o Aquesta m`etrica permet comparar quin slowdown(penalitzaci´o en el temps d’execuci´o) obtenim amb cada una de les execucions d’un workload. A l’eix x es representen les diferents execucions, una barra per cada execuci´o, mentre que a l’eix y hi ha el valor de l’slowdown. L’slowdown es calcula mitjan¸cant la divisi´o del temps d’execuci´o de cada treball respecte el temps requerit. At`es que els temps requerits estan molt ajustats per poder analitzar les difer`encies entre les diferents pol´ıtiques, l’slowdown ofereix una idea de quina execuci´o ha patit m´es penalitzaci´o. Es mostren dues barres per a cada execuci´o. La blava indica l’slowdown mig de tot el workload, mentre que la l´ınia taronja indica el valor m`axim i m´ınim de l’slowdown. La f´ormula utilitzada per calcular l’slowdown ´es: 4.6. AVALUACI ´ O DELS RESULTATS 37 Slowdown =T empsExecuci`o T empsSol·licitat Temps d’espera mig Aquesta m`etrica permet observar el temps mig d’espera dels treballs. A l’eix x es mostren les diferents configuracions i a l’eix y es mostra el temps. El temps d’espera, ´es el temps que passa des de que s’envia el treball al sistema de cues fins que s’executa. Estat de finalitzaci´o de les aplicacions Aquesta m`etrica permet analitzar quin ´es el comportament de cada pol´ıtica i veure quantitativament l’estat de finalitzaci´o dels treballs de cada execuci´o. A l’eix de les x es representen les diferents execucions, mentre que a l’eix de les y es representa el nombre d’aplicacions. Per a cada execuci´o es disposen 4 barres; la blava indica el nombre de treballs matats (Killed) per exc´es de temps, la taronja, el nombre de treballs que han excedit el seu temps requerit, per`o que han finalitzat dins dels 5 minuts addicionals (OverTime). La barra groga indica el nombre de treballs que han finalitzat correctament (Completed) i, finalment la barra verda indica el nombre d’aplicacions que han fallat (Failed). Aquest ´ultim cas nom´es es d´ona en les execucions de Less Consume, ja que els workloads contenen dos treballs de 32 cpus amb una alta demanda d’ample de banda de mem`oria. Aquest fet provoca que Less Consume no sigui capa¸c d’assignar un conjunt de cpus que satisfaci les necessitats d’ample de banda dels treballs mantenint la penalitzaci´o m`axima per sota del llindar estipulat pel treball. Aix`o es podria sol·lucionar considerant el nombre de cpus sol·licitades pel treball com a un m`axim i no com un requisit. Percentatge d’´us de les CPUs Aquesta m`etrica ens permet analitzar quina ´es la utilitzaci´o de les cpus del sistema durant l’execuci´o del workload. A l’eix de les x es representen les diferents execucions amb una barra per cada una i, a l’eix de les y es representa el percentatge d’utilitzaci´o de les cpus. Aquesta m`etrica s’extreu calculant la mitjana de la mitjana d’´us de cada cpu. Pencentatge d’´utilitzaci´o ´util de les CPUs Aquesta m`etrica permet observar el percentatge d’ocupaci´o del sistema per aquells treballs que finalitzen correctament. Es considera que un treball finalitza correctament si acaba la seva execuci´o dins del temps requerit. 38 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS ´ Us de cada CPU (gr`afica paraver) Aquesta ´es tamb´e una m`etrica extreta amb Paraver. De la mateixa manera que les anteriors, a l’eix de les x es representa el temps, mentre que a l’eix de les y es representen les cpus, una l´ınia per cada una. Quan una cpu est`a assignada a un treball es representa en blau, mentre que si no est`a assignada es representa en negre. Amb aquesta m`etrica es pot observar com es reparteixen les cpus i com a mesura que s’incrementa el llindar de penalitzaci´o l’´us de les cpus augmenta. 4.6.2 Escenari HIGH En aquest escenari ´es en el que es pot apreciar m´es difer`encia entre les diferents pol´ıtiques de selecci´o de recursos. Com es pot veure a la figura 4.9, hi ha una gran difer`encia entre el temps d’execuci´o del workload CR respecte dels altres. Com ´es d’esperar, la primera execuci´o del workload (CR) ´es la que menys temps d’execuci´o t´e, mentre que l’execuci´o m´es llarga ´es la LC. Tamb´e es pot apreciar com es va reduint el temps d’execuci´o total a mesura que s’augmenta el llindar m`axim de penalitzaci´o. Tamb´e s’observa que a l’execuci´o de CR gaireb´e no hi ha temps sobrant de les aplicacions (color blanc). Aix`o ´es degut a qu`e, en la majoria dels casos les aplicacions consumeixen tot el seu temps, o excedeixen el temps sol·licitat. Si una aplicaci´o excedeix en 5 minuts el temps sol·licitat, temps addicional proporcinat amb el par`ametre de configuraci´o OverTimeLimit, SLURM la mata(kill). En el cas de les execuci´ons de Less Consume tamb´e es pot apreciar un augment considerable del temps d’espera respecte a l’execuci´o de CR. Aix`o ´es degut a qu`e, en aquest escenari, en haver-hi moltes aplicacions amb una gran demanda d’ample de banda, la pol´ıtica Less Consume fa esperar una aplicaci´o fins que la compartici´o d’ample de banda de mem`oria no suposi una penalitzaci´o superior al llindar m`axim perm`es. Per tant, com es pot apreciar a les traces presentades, el temps d’espera es va redu¨ınt a mesura que s’augmenta el llindar de penalitzaci´o. A la figura 4.10, es pot observar l’ample de banda assignat a cada un dels nodes. Es pot apreciar clarament que l’execuci´o CR no t´e cap mena de control sobre l’ample de banda de mem`oria assignat, i gaireb´e en tot moment els nodes es troben sobrecarregats. Aquest fet contrasta amb l’execuci´o LC, en la que en cap moment hi ha cap node sobrecarregat, com era d’esperar doncs LC s´ı que realitza un control sobre l’ample de banda de mem`oria de cada node i treball. A mesura que s’augmenta el llindar perm`es es pot apreciar com es van saturant els nodes fins al cas de l’execuci´o LC1.2RP en la qu`e pr`acticament s’arriba a uns nivells de saturaci´o semblants als de l’execuci´o CR. Tot i que en aquesta gr`afica no es pot apreciar, a la figura 4.11 es pot veure un resum de l’ample de banda assignat a tot el sistema. D’aquesta manera es pot observar com l’ample de banda assignat de l’execuci´o CR ´es molt superior al de l’execuci´o LC1.2RP. Aix`o provoca una 4.6. AVALUACI ´ O DELS RESULTATS 39 Figura 4.9: HIGH: Vista del proc´es de les aplicacions en les diferents execucions del workload. penalitzaci´o en els treballs molt m´es elevada en el cas de CR que en el cas de LC1.2RP. Tamb´e es pot observar que l’ample de banda de mem`oria de tot el sistema en el cas de LC1.2RP no arriba mai a 30000MB/s mentre que l’execuci´o de CR supera aquesta xifra durant gran part de la seva execuci´o. A la figura 4.12 es pot veure un resum de l’slowdown de l’execuci´o de les aplicacions respecte al temps d’execuci´o sol·licitat i el temps mig d’espera dels treballs. En aquest cas es pot observar com la mitjana d’slowdown(barra blava) ´es molt superior en el cas de CR respecte a les execucions de Less Consume. Tamb´e el m`axim i m´ınim(barra taronja) s´on molt superiors en el cas de l’execuci´o de CR que en els altres casos, aproximadament el doble. Un fet curi´os ´es que l’slowdown m`axim obtingut per les execucions de Less Consume supera el llindar establert en cada una de les execucions. Aquest fet ´es degut a que l’ample de banda de mem`oria no ´es l’´unic factor determinant a l’hora d’executar una aplicaci´o, ja que la distribuci´o de les tasques en els diferents nodes o l’ample de banda de xarxa tamb´e s´on factors que s’haurien de tenir en compte i que poden provocar que les aplicacions s’executin m´es lentament de l’esperat. La utilitzaci´o del par`ametre que permet augmentar la penalitzaci´o, mostra un augment de l’slowdown mig dels treballs. 40 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS Figura 4.10: HIGH: Vista de l’´us d’ample de banda de mem`oria de cada Node en les diferents execucions. Tamb´e es pot observar com l’´us de Less Consume dispara el temps d’espera mig dels treballs i com la utilitzaci´o dels llindars de penalitzaci´o redueixen considerablement aquest temps. Teamb´e es pot observar una disminuci´o del temps d’espera utilitzant el par`ametre que permet augmentar la penalitzaci´o dels treballs ja comen¸cats. Una altra dada a tenir en compte a l’hora de comparar les diferent execucions ´es l’estat de finalitzaci´o dels treballs. A la figura 4.13 es pot veure un resum de l’estat en el qu`e han acabat els diferents treballs executats en les diferents execucions del workload. Es pot observar que l’execuci´o de CR t´e un gran nombre d’aplicacions que han hagut de ser aturades per SLURM per haver excedit els 5 minuts extres respecte el temps sol·licitat(franja blava). En la resta d’execucions gaireb´e no hi ha cap aplicaci´o que s’hagi hagut de matar. Tamb´e s’observa un gran nombre de treballs que han finalitzat dins dels 5 minuts extres(franja taronja), mentre que en les execucions de Less Consume gaireb´e no n’hi ha, excepte en el cas de LC1.2RP. Cal remarcar l’aspecte negatiu que apareix en totes les execucions de Less Consume, aix`o ´es, que aquestes mostren dos treballs que han fallat(franja verda). Aquests 4.6. AVALUACI ´ O DELS RESULTATS 41 Figura 4.11: HIGH: Vista de l’´us d’ample de banda de mem`oria del sistema en dues execucions. Figura 4.12: HIGH: Slowdown en cada una de les execucions s´on dos treballs que sol·liciten 32 cpus i un ample de banda de mem`oria elevat, el qu`e provoca que Less Consume no sigui capa¸c de trobar una assignaci´o v`alida per a aquests dos treballs que no superi el llindar m`axim perm`es de penalitzaci´o, i per tant rebutja els dos treballs. Un fet no esperat ´es l’aparici´o de treballs matats en les execucions de Less Consume. Tot i que en les dues primeres execucions (LC i LC1,1R) no s’aprecia cap treball matat, a les tres execucions seg¨uents s´ı que apareixen aplicacions que s’ha matat per excedir-se del temps requerit. Aquest fet ve donat per la compartici´o d’altres recursos apart de l’ample de banda de mem`oria, com pot ser l’ample de banda de xarxa, i tamb´e per la distribuci´o de les tasques en els nodes, ja que una aplicaci´o no es comporta de la mateixa manera si es col·loquen dues tasques per node o nom´es una. Es pot observar tamb´e que en les configuracions en qu`e es permet augmentar la penalitzaci´o dels treballs ja comen¸cats, augmenten el nombre de treballs que excedeixen el seu temps requerit respecte a les configuracions que no permeten augmentar la penalitzaci´o. A la figura 4.14, es pot observar el percentatge mig d’´us de les cpus durant tota l’execuci´o i 48 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS Consume la utilitzaci´o de les cpus ´es molt alta. Aquest fet ´es degut a que el backfilling ´es capa¸c de col·locar els treballs petits en els forats que queden lliures, i a mesura que els treballs petits es van acabant i nom´es queden els m´es grans, a utilitzaci´o de les cpus va disminuint. Figura 4.22: MEDIUM: Vista de l’´us de cada CPU en els diferents workloads. 4.6.4 Escenari LOW En aquest escenari la majoria d’aplicacions tenen uns requisits molt baixos d’ample de banda de mem`oria. Aquest fet provoca que gaireb´e cap treball tingui penalitzaci´o. A la figura 4.23 es pot observar com totes les execucions del workload tenen una duraci´o similar. Pot resultar extrany observar que l’execuci´o que m´es triga en acabar ´es la de LC1.2R. Aquest fet ´es degut a que el treball 50 es passa molta estona esperant per a ser executat a causa de no tenir prous processadors lliures que estant essent utilitzats pels treballs 48 i 49. Tamb´e es pot observar, de la mateixa manera que a l’escenari anterior, que hi ha molts treballs que acaben la seva execuci´o abans del temps requerit, sobretot a les execucions LC1.2. Aix`o ve donat perqu`e l’augment del temps requerit ´es superior a la penalitzaci´o obtinguda pel treball, el que fa que aquest pugui executar-se a una velocitat normal, i per tant li sobri gaireb´e tot el temps addicional. 4.6. AVALUACI ´ O DELS RESULTATS 49 Figura 4.23: LOW:Vista del process de les aplicacions en els diferents workloads Un altre tret a destacar d’aquestes execucions ´es que el temps d’espera ´es pr`acticament el mateix a les execucions CR i LC, contr`ariament al que es podria esperar. Aix`o est`a provocat per la gran cuantitat de treballs amb una demanda molt baixa d’ample de banda de mem`oria, fet que provoca que aquest par`ametre dels treballs pr`acticament no tingui import`ancia a l’hora de realitzar la selecci´o de recursos, ja que dif´ıcilment hi haur`a penalitzaci´o entre treballs. Com es pot observar a la figura 4.24, l’ample de banda acumulat a cada node ´es molt baix, i fins i tot en el cas de l’execuci´o de CR gaireb´e no hi ha saturaci´o dels nodes. Com era d’esperar en aquest escenari, gaireb´e no hi ha saturaci´o en cap cas, excepte a l’execuci´o de LC1.2RP tot i que en aquesta la saturaci´o t´e una durada for¸ca curta. Com es pot veure a la figura 4.25, l’ample de banda acumulat del sistema ´es pr`acticament el mateix en les execucions CR i LC1.2RP. De fet a la primera part de l’execuci´o les dues gr`afiques es solapen degut a que l’assignaci´o d’ample de banda de mem`oria ´es exactament la mateixa en les dues execucions. Cal destacar, que tot i que a la gr`afica anterior s’ha observat una saturaci´o d’algun dels nodes del sistema, aquest fet no ´es observable amb aquesta m`etrica doncs en cap 50 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS Figura 4.24: LOW:Vista de l’´us d’ample de banda de cada Node en els diferents workloads. moment es sobrepassa l’acumulat d’ample de banda de mem`oria dels nodes. Com ´es d’esperar en aquest escenari, l’slowdown de les execucions ´es pr`acticament id`entic en tots els casos com mostra la figura 4.26, obtenint l’execuci´o de CR fins i tot millors resultats que algunes de les execucions de Less Consume. En aquest escenari les difer`encies entre les diferents configuracions i valors del llindar m`axim s´on pr`acticament inexistents. Tot i aix´ı, hi ha una clara difer`encia entre el temps d’espera mig de l’execuci´o amb LC i la resta que utilitzen Less Consume. Pel qu`e fa a la finalitzaci´o dels treballs, per`o, els resultats no s´on exactament els esperats. Com es pot observar a la figura 4.27 hi ha un gran nombre de treballs matats, sobretot en l’execuci´o de CR i, tamb´e hi ha un gran nombre d’aplicacions que s’han excedit del temps sol·licitat. Aquest fet demostra que l’ample de banda de mem`oria no ´es l’´unic element que pot provocar un ralentiment de l’execuci´o dels treballs. De la mateixa manera que a l’escenari anterior, l’augment del temps sol·licitat en el cas de les execucions LC1.2 permet que acabin moltes m´es aplicacions que no pas en les altres execucions. 4.6. AVALUACI ´ O DELS RESULTATS 51 Figura 4.25: LOW: Vista de l’´us d’ample de banda de mem`oria del sistema en dues execucions. Figura 4.26: LOW: Slowdown en cada una de les execucions Com tamb´e era d’esperar, la utilitzaci´o de les cpus ´es for¸ca alta com es pot observar a la figura 4.28, arribant al 86% en el cas de l’execuci´o de CR. El cas a destacar ´es el de l’execuci´o de LC1.2R que est`a molt per sota de la resta amb un 76% d’´us de cpus. Aquest fet s’explica, com es pot veure a la figura 4.29, perqu`e cap al final la meitat dels processadors estan parats esperant a que acabi el treball que est`a situat a la segona meitat del sistema. Aquest fet ´es el que provoca que la mitjana d’´us de les cpus baixi considerablement en aquesta execuci´o del workload. Es pot observar clarament en la gr`afica d’utilitzaci´o ´util de cpu, com l’augment del llindar tenen un clar impacte en l’´us util de les cpus. Quant m´es s’augmenta el llindar m´es gran ´es la utlitzaci´o ´util del sistema, donat que la penalitzaci´o ´es molt inferior al llindar per`o sempre s’aplica l’augment del temps sol·licitat. 52 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS Figura 4.27: LOW: Estat de finalitzaci´o dels treballs 4.6.5 An`alisi Conjunt Com s’ha vist a les seccions anteriors hi ha molta difer`encia en el comportament de les diferents pol´ıtiques de selecci´o de recursos. En tots els escenaris la pol´ıtica CR ´es la m´es r`apida en executar tots els treballs, per`o tamb´e ´es amb la que es maten m´es treballs i amb la que acaben m´es treballs dins del temps addicional que proporciona SLURM als treballs. Si no fos per aquest temps en el cas de l’escenri HIGH pr`acticament tots els treballs es matarien per excedir el temps sol·licitat. Aques per`o no ´es el cas de les execucions amb Less Consume. Si b´e aquestes s´on molt m´es lentes que Consumable Resources, la quantitat de treballs que es maten o que acaben fora del seu temps s´on moltes menys. Un fet que cal tenir en compte i que juga a favor de la pol´ıtica Consumable Resources ´es la utilitzaci´o de les cpus. Tal i com es realitza actualment la comptabilitat d’hores en els centres de supercomputaci´o, el m´es important ´es omplir al m`axim el sistema, ja que es factura per hora de cpu utilitzada per`o no per hora de cpu ´util. Per a poder aplicar Less Consume en un entorn real caldria aplicar nous models de comptabilitat d’hores basats en la utilitzaci´o de recusos i no ´unicament en hores de cpus. ´ Es a dir, si un treball sol·licita tot l’ample de banda de mem`oria d’un node per cada una de les seves tasques, aquest treball realment est`a utilitzant tot el node, doncs est`a evitant que altres treballs puguin executar-se en aquell node i, per tant s’hauria de comptabilitzar que realment utilitza tot el node i no tansols una cpu. Com s’ha pogut comprovar en les anterior seccions, la penalitzaci´o en el temps d’execuci´o es mant´e practicament invariant en els diferents escenaris utilitzant Less Consume mentre que la utilitzaci´o de Consumable Resources obt´e una penalitzaci´o mitja superior a les altres execucions. 4.6. AVALUACI ´ O DELS RESULTATS 53 Figura 4.28: LOW: Percentatge d’utilitzaci´o de les CPUS Figura 4.29: LOW: Vista de l’´us de cada CPU en els diferents workloads. Tamb´e es pot observar com els temps d’espera de Consumable Resources s´on inferiors en els casos en que hi ha saturacions en els nodes i com l’augment del llindar m`axim de penalitzaci´o i el pemetre l’augment de la penalitzaci´o dels treballs ja executant-se provoquen una disminuci´o 54 CAP´ ITOL 4. AVALUACI ´ O I AN ` ALISI DE RESULTATS del temps d’espera en tots els escenaris. Tot i que en la utilitzaci´o de cpu, Consumable Resources ´es molt superior a Less Consume, en la utilitzaci´o ´util de cpu Less Consume es comporta millor. En tots els casos la majoria d’execucions de Less Consume s´on clarament superiors en quant a percentatge d’utilitzaci´o ´util de la cpu, essent les execucions amb un llindar m´es elevat les que obtenen els millors resultats. Aix´ı doncs podem concloure, que la millor combinanci´o de llindar m`axim de penalitzaci´o i de par`ametres de configuraci´o de la pol´ıtica ´es Less Consume amb un llindar de 1,2 i el par`ametre de configuraci´o LC REQ TIME PENALTY, ja que ofereix una disminuci´o important del temps d’espera respecte a Less Consume sense llindar, la penalitzaci´o en el temps d’execuci´o ´es pr`acticament la mateixa que Less Consume i el percentatge d’utilitzaci´o ´util de les cpus ´es clarament superior. CAP´ ITOL 5 Planificaci´o i An`alisi econ`omic L’objectiu d’aquest cap´ıtol ´es donar una idea del cost del treball realitzat durant el projecte. La primera part mostra la planificaci´o del projecte per a poder comptabilitzar les hores dedicades i, per altra banda el cost dels equipaments utilitzats per obtenir finalment el cost econ`omic del projecte. 5.1 Planificaci´o A continuaci´o es fa un rep`as de la planificaci´o temporal del projecte. A la figura 5.1 es pot veure aquesta planificaci´o. T´e una resoluci´o setmanal, i va des de finals de setembre del 2009 fins a mitjans de juny del 2010. S’han dedicat 4 hores di`aries, excepte a la ´ultima fase del projecte on la dedicaci´o ha estat superior. Al diagrama es pot apreciar visualment l’evoluci´o de les diferents fases del projecte. S’ha dividit el projecte en 4 gran etapes: la concepci´o del projecte, el desenvolupament, l’an`alisi i la documentaci´o del projecte. La primera fase consisteix principalment en la recerca de informaci´o, per`o tamb´e inclou un estudi de la viabilitat d’implementaci´o del projecte dins d’SLURM i la manera de fer-ho. La fase de desenvolupament consisteix, en l’implementaci´o dels requeriment previs per poder implementar la pol´ıtica Less Consume, la implementaci´o de la pol´ıtica b`asica i el plugin d’accounting i finalment la implementaci´o de les millores. Totes les tasques d’aquesta fase inclouen tamb´e les proves respectives per a garantir un correcte funcionament. La fase d’avaluaci´o inclou la preparaci´o de l’entorn per poder realitzar les proves, l’execuci´o i tria de les aplicacions a executar dins els workloads i l’execuci´o i an`alisi dels workloads en els 55 56 CAP´ ITOL 5. PLANIFICACI ´ O I AN ` ALISI ECON ` OMIC diferents escenaris. Finalment, la fase de documentaci´o, inclou la redacci´o de l’informe previ, lliurat el dia 10 d’abril i la redacci´o d’aquesta mem`oria. Figura 5.1: Planificaci´o temporal del projecte 5.2. AN ` ALISI ECON ` OMIC 57 5.2 An`alisi econ`omic El cost del projecte est`a dividit en dues parts. Per una banda hi ha el cost de la implementaci´o dels dos plugins desenvolupats i de la preparaci´o de l’entorn i, per l’altra banda hi ha el cost de l’equipament on s’han realitzat les proves. Cost d’implementaci´o Per a comptabilitzar el cost de la implementaci´o s’ha considerat que tot el treball dut a terme l’ha realitzat un programador. Aquestes hores inclouen la part de documentaci´o, la implementaci´o dels dos plugins, l’execuci´o de les proves i la preparaci´o de l’entorn d’execuci´o. La taula 5.1 mostra el cost d’implementaci´o: Perfil Hores Preu/Hora Total Programador 500 25e12500e Taula 5.1: Cost d’implementaci´o del projecte Cost de l’equipament Per a calcular el cost de l’equipament, es considerar`a ´unicament l’´us de MareNostrum. Com que MareNostrum no s’ha utilitzat en exclusiva, es calcula a partir de les hores de c´alcul utilitzades, com si es tract´es de qualsevol usuari. A la taula 5.2 es motra el cost total de l’´us de l’equipament. Concepte Hores Preu/Hora Total MareNostrum 6500 0.30e1950e Taula 5.2: Cost de l’equipament utilitzat Cost Total Finalment, a la taula 5.3 es mostra el cost total del projecte. Concepte Cost Cost Implementaci´o 12500e Cost Equipament 1950e Total 14450e Taula 5.3: Cost total del projecte 64 AP` ENDIX A. WORKLOADS GENERATS A.3 LOW High : 10 Medium: 10 Low : 80 File : workload . txt HIGH : 5 MEDIUM: 2 LOW : 43 18 00:00:50 4 cg .B.4 50 580 46 00:04:33 2 cg .B.2 167 570 233 00:06:15 4 cg.B .4 375 580 271 01:22:54 8 cg.B .8 9212 445 322 00:01:34 1 sinteticmed 8 1050 369 00:02:53 2 cg.B .2 106 570 573 00:01:40 4 cg.B .4 100 580 620 00:05:25 4 cg.B .4 325 580 668 00:02:55 4 cg.B .4 175 580 855 00:15:24 8 cg.B .8 1712 445 1094 00:05:45 1 sinteticlow 51 83 1160 00:05:52 1 sinteticlow 52 83 1222 00:10:23 1 sinteticlow 92 83 1227 01:34:28 1 sinteticlow 836 83 1269 00:37:30 4 cg.B.4 2250 580 1372 00:02:04 8 cg.B.8 231 445 1401 00:48:00 4 cg.B.4 2880 580 1506 00:22:10 16 sp .C .16 1538 480 1644 00:11:39 8 cg.B.8 1296 445 1749 00:04:10 4 cg.B.4 250 580 1877 01:58:11 8 cg.B.8 13133 445 1952 00:09:34 16 sp.C.16 664 480 2042 00:06:33 1 sinteticlow 58 83 2087 00:00:49 2 cg.B.2 30 570 2124 01:47:28 8 cg.B.8 11942 445 2199 01:18:38 8 cg.B.8 8738 445 2340 01:28:02 4 cg.B.4 5282 580 2614 00:08:14 1 sinteticlow 73 83 2648 01:24:44 4 cg.B.4 5084 580 2810 00:04:09 8 cg.B.8 462 445 2978 00:04:09 16 sp.C.16 289 480 3171 00:03:44 1 sinteticmed 19 1050 3217 00:28:45 4 cg.B.4 1725 580 3323 00:22:04 8 cg.B.8 2453 445 3387 00:01:38 2 cg.B.2 60 570 3429 00:04:16 4 cg.B.4 256 580 3528 01:53:13 1 sinteticlow 1002 83 3727 00:22:49 1 sinteticlow 202 83 3776 00:07:06 32 cg.D.32 17 1440 3911 00:13:56 1 sintetichigh 50 1935 3989 00:07:54 1 sinteticlow 70 83 4128 00:00:00 8 cg.D.8 0 1600 4488 01:15:01 1 sinteticlow 664 83 4643 00:07:55 4 cg.B.4 475 580 4707 00:06:39 8 cg.B.8 740 445 5070 00:05:01 32 cg.D.32 12 1440 5116 01:16:09 8 cg.B.8 8462 445 5182 00:37:23 4 sintetichigh 134 1935 5301 01:01:53 16 sp .C .16 4293 480 5395 00:06:21 4 cg.B.4 381 580 AP` ENDIX B Codi benchmark propi #include < stdlib .h > #include < stdio .h > #include <mpi .h> #include "/ gpfs / apps / CEPBATOOLS / mpitrace /64/ include / mpitrace_user_events .h" #include <math .h> #include < sched .h > #define SIZE 256000000 #define STRIDE 64 #ifdef NITER # define ITERS NITER #else # define ITERS 60 #endif int main(int argc , char ** argv ){ unsigned int index , disp ,iter , rank ; int *data ; int niter ; void ** p; unsigned long mask ; MPI_Init ( &argc , &argv ); MPI_Comm_rank ( MPI_COMM_WORLD , &rank ); data = malloc ( SIZE * sizeof(int) + 1) ; /∗acc ess the vector : We d i v i de d the vector in chunks of <s t r i d e >e n t r i e s each . We access the f i r s t element of each chunk , then the second of each chunk , e tc . We repeat t h i s process ITERS times 1.) 1.1) x [0∗s t r i d e +0] , x [1∗s t r i d e +0] , x [2∗s t r i d e +0] , . . . 1.2) x [0∗s t r i d e +1] , x [1∗s t r i d e +1] , x [2∗s t r i d e +1] , . . . 65 66 AP` ENDIX B. CODI BENCHMARK PROPI ... 1 . n) x [0 ∗s t r i d e+s t r i d e −1] , x [1∗s t r i d e+s t r i d e −1] , x [2∗stride+ s t r i d e −1] , . . . x [ s t r i d e −1] , x [2∗s t r i d e −1] , x [3∗ s t r i d e −1\ ] , . . . 2. ) IDEM ... LOOP\ITERATION. ) IDEM ∗/ p = data ; // I n i c i a l i t z a c i o d e l t r a c ei g //MPItrace\i n i t ( ) ; for( iter =0; iter < ITERS ; iter ++) { disp = 0; // I n i c i de la i t e r a c i o //MPItrace\eventandcounters (1000 , 1) ; while (1) { for ( index = 0; index <= ( SIZE - STRIDE ); index += STRIDE ) { p = &( data [ index + disp ]) ; p = *p; } i f (++ disp == STRIDE ) { p = data ; break; } printf(" Iter :% d\n" ,disp ); } //Fi iteracio //MPItrace\eventandcounters (1000 , 0) ; } // F i n a l i t z a c i o t r a c e i g //MPItrace\f i n i () ; MPI_Finalize(); return 0; } Bibliografia [BSC] BSC, http://www.bsc.es. [CCF+99] Steve J. Chapin, Walfredo Cirne, Dror G. Feitelson, James Patton Jones, Scott T. Leutenegger, Uwe Schwiegelshohn, Warren Smith, and David Talby, Benchmarks and standards for the evaluation of parallel job schedulers, JSSPP, 1999, pp. 67–90. [Gui] Francesc Guim, Job-guided scheduling strategies for multi-site hpc infrastructures, Ph.D. thesis. [LF03] Uri Lublin and Dror G. Feitelson, The workload on parallel supercomputers: modeling the characteristics of rigid jobs, J. Parallel Distrib. Comput. 63 (2003), no. 11, 1105– 1122. [Par] Paraver, http://www.bsc.es/plantillaA.php?cat id=485. [SLU] Simple linux utility for resource management, http://computing.llnl.gov/linux/slurm/. [TOP] Top500 Supercomputer Sites, http://www.top500.org. 67