Denne siden dokumenterer køsystemet på Colossus klyngen (HPC for TSD).
I TSD har hvert prosjekt sin egen virtuelle Linux-maskin (VM) for å sende inn jobber til klyngen.
Submitte jobb
For å kjøre en jobb på klyngen, sender du et jobbskript inn i jobbkøen, og jobben startes når en eller flere egnede beregningsnoder er tilgjengelige. Jobbkøen administreres av et køsystem kalt Slurm ().
Vær oppmerksom på at jobscript-navn ikke skal inneholde sensitiv informasjon.
Job scripts are submitted with the sbatch command:
Jobbskript sendes inn til køsystemet med sbatch kommandoen:
sbatch YourJobscript
Kommandoen sbatch returnerer en jobid, et id-nummer som identifiserer den innsendte jobben. Jobben vil vente i jobbkøen til det er ledige dataressurser den kan bruke. En jobb i den tilstanden sies å være pending (PD). Når den har startet kalles den running (R). Eventuelle utdata (stdout eller stderr) fra jobbskriptet vil bli skrevet til en fil kalt slurm-jobid.out i katalogen der du kjørte sbatch, med mindre annet er spesifisert.
Alle kommandoer i jobbskriptet utføres på beregningsnoden(e) som er tildelt av køsystemet. Skriptet spesifiserer også en rekke krav (minnebruk, antall CPUer, kjøretid osv.), som brukes av køsystemet for å finne en eller flere egnede maskiner for jobben din.
Du kan avbryte kjørende eller ventende (pending) jobber med scancel:
scancel jobid # Cancel job with id jobid (as returned from sbatch) scancel --user=MyUsername # Cancel all your jobs scancel --account=MyProject # Cancel all jobs in MyProject
Se man scancel for flere detaljer.
Prosjektkvote
PÃ¥ Colossus har hver bruker kun tilgang til et enkelt prosjekt, hvis navn (pNN) er prefikset til brukernavnet. Prosjekter kan ha tilgang til opptil 3 allokeringer av beregningsressurser i TSD:
- TSD allokering
- Sigma2 allokering
- Dedicated allokering
TSD allokering
For å bruke denne ressursen, må jobber sendes inn med "--account=pNN_tsd"-argumentet. Hvor pNN er ditt prosjektnummer.
Sigma2 allokering
Kun TSD-prosjekter med cpu-timekvote fra Sigma2 kan bruke denne poolen. Vi anbefaler ethvert prosjekt med betydelige beregningsbehov å be om CPU (og disk) kvote fra Sigma2 som beskrevet her. Sigma2-kvoten er gyldig i 6 måneders perioder, med start 1. april og 1. oktober.
For å bruke denne ressursen, må jobber sendes inn med "--account=pNN"-argumentet. Hvor pNN er ditt prosjektnummer.
Hvis du sender til denne ressursen, men prosjektet ikke har en Sigma2-kvote, vil jobbene forbli pending (PD) med årsaksmeldingen "AssocGrpBillingMinutes".
Dedikert allokering
Alle andre databehandlings- og gpu-noder i Colossus ble anskaffet av individuelle prosjekter for privilegert tilgang, men vedlikeholdes av TSD.
For å bruke denne ressursen, må jobber sendes inn med argumentet "--account=pNN_reservationname". Hvor pNN er ditt prosjektnummer og reservasjonsnavnet navnet på den dedikerte ressursen.
Inspisere kvote
Kommandoen cost kan brukes til å inspisere kvoten og se hvor mye av den som er brukt og hvor mye som gjenstår. Dette gjelder både den ikke-regnskapspliktige UiO-kvoten (oppført som ikke-anvendbar, NA), samt den regnskapspliktige Sigma2-kvoten (men ikke andre private tildelinger). For prosjekter med en fakturerbar Sigma2-kvote, vil det typisk se slik ut:
-bash-4.2$ cost Report for project p1337 on Colossus Allocation period 2023.1 (2023-04-01 -- 2023-10-01) Last updated on Mon Jun 12 14:42:04 2023 ============================================================= Account Description Billing hours % of quota ============================================================= p1337 Used (finished) 109.15 5.5 % p1337 Reserved (running) 0.00 0.0 % p1337 Pending (waiting) 0.00 0.0 % p1337 Available 1890.85 94.5 % p1337 Quota 2000.00 100.0 % ============================================================= ============================================================= Account Description Billing hours % of quota ============================================================= p1337_tsd Used (finished) 9.51 NA p1337_tsd Reserved (running) 0.00 NA p1337_tsd Pending (waiting) 0.00 NA p1337_tsd Available NA NA p1337_tsd Quota NA NA =============================================================
For prosjektene uten en Sigma2 cpu-timekvote, vil det typisk se slik ut:
-bash-4.2$ cost Report for project p77 on Colossus Allocation period 2023.1 (2023-04-01 -- 2023-10-01) Last updated on Mon Jun 12 14:25:44 2023 ============================================================= Account Description Billing hours % of quota ============================================================= p77 Used (finished) 0.00 NA p77 Reserved (running) 0.00 NA p77 Pending (waiting) 0.00 NA p77 Available 0.00 NA p77 Quota 0.00 NA ============================================================= ============================================================= Account Description Billing hours % of quota ============================================================= p77_tsd Used (finished) 0.00 NA p77_tsd Reserved (running) 0.00 NA p77_tsd Pending (waiting) 0.00 NA p77_tsd Available NA NA p77_tsd Quota NA NA ============================================================= The project does not have a Sigma2 quota for the current period. See /english/services/it/research/sensitive-data/use-tsd/hpc/queue-system.html#toc2 for information.
Legg merke til at "Available" viser "Quota" minus "Used", "Reserved" og "Pending". Så "Available" er det som forventes å være tilgjengelig hvis alle kjørende og ventende jobber bruker timene de spesifiserer. (Vanligvis spesifiserer jobber lengre --time enn de faktisk bruker, så "Available" vil vanligvis øke etter hvert som jobbene avsluttes.)
Man kan også liste opp bruken per bruker i prosjektet ved å legge til "--details":
cost --details
Dette vil legge til kvotebruken per bruker:
Report for project p1337 on Colossus Allocation period 2023.1 (2023-04-01 -- 2023-10-01) Last updated on Mon Jun 12 14:38:03 2023 ============================================================= Account Description Billing hours % of quota ============================================================= p1337 Used (finished) 109.15 5.5 % p1337 Reserved (running) 0.00 0.0 % p1337 Pending (waiting) 0.00 0.0 % p1337 Available 1890.85 94.5 % p1337 Quota 2000.00 100.0 % ============================================================= Account User Used billing hours % of quota ============================================================= p1337 p1337-bartt 95.36 4.8 % p1337 p1337-bhm 13.79 0.7 % ============================================================= ============================================================= Account Description Billing hours % of quota ============================================================= p1337_tsd Used (finished) 9.51 NA p1337_tsd Reserved (running) 0.00 NA p1337_tsd Pending (waiting) 0.00 NA p1337_tsd Available NA NA p1337_tsd Quota NA NA ============================================================= Account User Used billing hours % of quota ============================================================= p1337_tsd p1337-bartt 8.48 NA p1337_tsd p1337-haatveit 1.03 NA =============================================================
Se man cost for ytterligere detaljer om denne kommandoen.
Regnskap
Regnskap gjøres i form av faktureringsenheter, og kvoten er i faktureringsenhetstimer. Hver jobb er tildelt et antall faktureringsenheter basert på de forespurte CPUene, minnet og GPUene. Tallet som trekkes fra kvoten er antall faktureringsenheter multiplisert med (faktisk) veggtid (wall time) for jobben.
Antall faktureringsenheter for en jobb beregnes slik:
- Hver forespurt CPU får en kostnad på 1.
- Det forespurte minnet gis en kostnad basert på en minnekostnadsfaktor (se nedenfor).
- Den forespurte GPUen får en kostnad basert på en GPU-kostnadsfaktor (se nedenfor).
- Antall faktureringsenheter er det maksimale av CPU-kostnaden, minnekostnaden og GPU-kostnaden.
Minnekostnadsfaktoren og GPU-kostnadsfaktoren varierer mellom noder.
- For vanlige beregningsnoder er minnekostnadsfaktoren 0,12749 enheter per GiB. Dermed vil minnekostnaden for en jobb som ber om alt minne på en node være 64, antallet CPUer på noden.
- For GPU-noder er minnekostnadsfaktoren 0,09775967 enheter per GiB, og GPU-kostnadsfaktoren er 24 per GPU. Det betyr at en jobb som ber om alt minne, eller alle GPUer på en node, får en kostnad på 96, antall CPUer på noden.
- For bigmem-noder er minnekostnadsfaktoren 0,0323641 per GiB. Dermed vil minnekostnaden for en jobb som ber om alt minne på en node være 128, antallet CPUer på noden.
Når et prosjekt har overskredet kvotegrensen, vil jobbene stå på vent med årsaken "AssocGrpBillingMinutes".
Inspisere jobber
For å få en rask oversikt over statusen til en jobb, kan du bruke squeue:
squeue -j JobId
der JobId er jobb-ID-nummeret som sbatch returnerer. For å se flere detaljer om en jobb, bruk
scontrol show job JobId
Se man squeue og man scontrol for ytterligere detaljer om disse kommandoene.
Inspisere køen
Det er flere tilgjengelige kommandoer for å inspisere jobbkøen:
- squeue: liste opp jobber i køen
- pending: liste ventede (pending) jobber i køen
- qsumm: vis oppsummering av købruk
For å se listen over kjørende eller ventende jobber i køen, bruk kommandoen squeue. squeue vil kun vise jobbene i ditt eget prosjekt. Nyttige squeue alternativer:
[-j jobids] show only the specified jobs
[-w nodes] show only jobs on the specified nodes
[-t states] show only jobs in the specified states (pending, running,
suspended, etc.)
[-u users] show only jobs belonging to the specified users
All specifications can be comma separated lists. See man squeue for details. Examples:
Alle spesifikasjoner kan være kommadelte lister. Se man squeue for detaljer. Eksempler:
squeue -j 14132,14133 # shows jobs 4132 and 4133 squeue -w c1-11 # shows jobs running on c1-11 squeue -u foo -t PD # shows pending jobs belonging to user 'foo'
| Status | Text |
|---|---|
| PD | Pending |
| R | Running |
| S | Suspended |
| CG | Completing |
| CD | Completed |
| CF | Configuring |
| CA | Cancelled |
| F | Failed |
| TO | Timeout |
| PR | Preempted |
| NF | Node failed |
Du kan bruke pending kommandoen for å vise bare de ventende jobbene. Den viser jobbene i synkende prioritetsrekkefølge, og inkluderer et estimat for når jobben starter, når et slikt estimat er tilgjengelig. pending er ganske enkelt en innpakning rundt squeue, og godtar alle alternativer som squeue tar. Den vil også bare vise jobbene som tilhører ditt eget prosjekt.
For å se ressurssituasjonen til klyngen, bruk kommandoen qsumm. Den viser hvor mange prosessorer (eller rettere sagt, prosessorekvivalenter) som brukes av kjørende jobber og etterspørres av ventende jobber. Utdataene har to linjer, en for prosjektet ditt, og en som viser total bruk for alle prosjekter (inkludert prosjektet ditt). Et eksempel:
-------------------------------- Account Limit nRun nPend -------------------------------- p11 1536 20 11 Total 1536 1550 200 --------------------------------
Se qsumm --help for forklaringer av hver kolonne. Utdataene oppdateres hvert 5. minutt, så det kan ta et par minutter etter at jobber er sendt/startet/ferdig før det vises i qsumm-utdataene.
Generelle jobbbegrensninger
Standardverdier når ingenting er spesifisert
- 1 kjerne (CPU)
Resten (tid, mem per cpu osv.) må spesifiseres.
Grenser
- Maks "wall time" er 4 uker, men ikke send inn jobber som vil løpe i mer enn 7 dager med mindre man implementerer checkpointing: Ingen av nodene på Colossus har redundant strøm, og vi forbeholder oss retten til å stenge alle noder for vedlikehold når som helst med 7 dagers varsel!
- Maks 4500 innsendte jobber (løpende eller ventende) per prosjekt (
--account) samtidig. - Maks størrelse på jobbarrayer: 4000. Det betyr også at den største jobbarray indeksen er 4000. Merk at en jobbarray av størrelse N vil telle som N jobber mht. totalt antall innsendte jobber per prosjekt.
Planlegging
Jobber startes etter prioritet. Utestående jobber prioriteres iht
- Tid i køen
- Hvor mange jobber hver bruker har ventende i køen
Colossus starter jobber etter prioritet + tilbakefylling, så små, korte jobber kan starte tidligere enn jobber med høyere prioritet, så lenge de ikke forsinker de høyere prioriterte jobbene. I tillegg har vi lagt inn en begrensning på hvor mange jobber som tilhører en bruker som øker i prioritet over tid, for å unngå at en enkelt bruker hindrer alle andre brukere i å få jobber kjørt ved å sende inn et stort antall jobber samtidig. På denne måten vil prioriteringen i realiteten øke for brukere som kjører få jobber i forhold til brukere som kjører mange jobber. Dette er en avveining, og vi vil justere grensen (for tiden 10) hvis vi ser at effekten er for stor/liten.
Ring oss
Vi har åpent mellom 08:30 og 17:00 på hverdager,
og mellom 10:00 og 15:00 på lørdager.
Telefonnummer: 22 84 00 04
Send inn sak til oss
Du kan sende inn din forespørsel via e-post til: it-hjelp@uio.no.
Gå til e-postBook et videomøte over Zoom
Er du student eller ansatt kan du avtale veiledningstime hos UiO Helpdesk over Zoom. Tilgjengelige tider er tirsdag til torsdag mellom 11:00 og 13:00.
Book et videomøte