Jobb Script

Å kjøre en jobb på klyngen innebærer å lage et skallskript kalt et jobbskript. Jobbskriptet er en ren tekstfil som inneholder et hvilket som helst antall kommandoer, inkludert den primære kommandoen, dvs. den kan kopiere eller endre navn på filer, cd til riktig katalog osv., alt før du gjør den "ekte" jobben. Linjene i skriptfilen er kommandoene som skal utføres, i gitt rekkefølge. Linjer som starter med "#" ignoreres som kommentarer, bortsett fra linjer som starter med "#SBATCH" som ikke blir utført, men inneholder spesielle instruksjoner til køsystemet.

Hvis du ikke er kjent med shell-skript, er de ganske enkelt et sett med kommandoer som du kunne ha skrevet på kommandolinjen. Du kan finne mer informasjon om shell scripts her: Introduction to Bash shell scripts.

Et jobbskript består av flere elementer:

• Instruksjoner til køsystemet
• Kommandoer for å sette opp miljøet hvor jobbene kjøres
• De faktiske kommandoene som skal kjøres

Instruction parameters to the queue system may be specified on the sbatch command line and/or in #SBATCH lines in the job script. There can be as many #SBATCH lines as you need, and you can combine several parameters on the same line. If a parameter is specified both on the command line and in the jobscript, the parameter specified on the command line takes precedence. The #SBATCH lines should precede any commands in the script. A couple of parameters are compulsory. If they are not present, the job will not run:

Instruksjonsparametere til køsystemet kan spesifiseres på sbatch-kommandolinjen og/eller i #SBATCH-linjer i jobbskriptet. Det kan være så mange #SBATCH-linjer du trenger, og du kan kombinere flere parametere på samme linje. Hvis en parameter er spesifisert både på kommandolinjen og i jobbskriptet, har parameteren angitt på kommandolinjen forrang. #SBATCH-linjene skal komme foran alle kommandoer i skriptet. Et par parametere er obligatoriske. Hvis de ikke er til stede, vil ikke jobben kjøre:

• -account: Spesifiserer prosjektet jobben skal kjøre i. Hvis prosjektet ditt har en Sigma-kvote, vil dette være prosjekt (f.eks. p11). Hvis prosjektet ditt ikke har en Sigma-kvote, må du bruke tsd-reservasjonen, project_tsd (f.eks. p11_tsd).
• --time: Angir maksimal mulig kjøretid for jobben. Ikke spesifiser grensen for lav, fordi jobben vil bli drept hvis den ikke er ferdig innen denne tiden. På den annen side vil kortere jobber startes tidligere, så ikke spesifiser lenger enn du trenger. Standard maksimalt tillatt --time spesifikasjon er 1 uke; se detaljer her.
• --mem-per-cpu: Spesifiserer hvor mye RAM hver oppgave (standard er 1 oppgave; se Parallelle jobber) trenger for jobben. Teknisk sett spesifiserer denne grensen mengden internminne + swap jobben kan bruke. Hvis jobben prøver å bruke mer enn denne innstillingen, vil den bli drept. Det maksimale som kan bes om er det tilgjengelige minnet på noden (~500 GB på beregningsnodene). For eksempel:

  #SBATCH --mem-per-cpu=2000M

  Hvis jobben prøver å bruke mer enn 2000 MiB internminne som er forespurt i dette eksemplet, vil den bli drept. Merk at --mem-per-cpu er spesifisert per forespurt kjerne.

Kommandoene for å sette opp miljøet bør inkludere

module load SomeProgram/SomeVersion

jobsetup vil sette opp nødvendige miljøvariabler og skallfunksjoner, og må være den første kommandoen i skriptet. modulen vil sette opp miljøvariabler for å få tilgang til det angitte programmet. Det anbefales å spesifisere den eksplisitte versjonen i module load kommandoen. Vi oppfordrer deg også til å bruke

module purge

før module load, for å unngå å arve ukjente miljøvariableinnstillinger fra skallet du bruker til å sende inn jobben. Vi gir også råd om bruk av

set -o errexit

tidlig i skriptet. Dette gjør at skriptet avsluttes umiddelbart hvis en kommando etter denne mislykkes, i stedet for å gå videre til neste kommando. Dette gjør det mye lettere å finne ut om noe gikk galt i jobben, og i så fall hvor det skjedde.

En enkel seriell jobb

Dette er et skript for å kjøre en enkel, seriell jobb

#!/bin/bash

# Job name:
#SBATCH --job-name=YourJobname
#
# Project:
#SBATCH --account=YourProject
#
# Wall clock limit:
#SBATCH --time=hh:mm:ss
#
# Max memory usage:
#SBATCH --mem-per-cpu=Size

## Set up job environment:
module purge   # clear any inherited modules
set -o errexit # exit on errors

## Copy input files to the work directory:
cp MyInputFile $SCRATCH

## Make sure the results are copied back to the submit directory (see Work Directory below):
chkfile MyResultFile

## Do some work:
cd $SCRATCH
YourCommands

Erstatt reelle verdier for YourJobname, YourProject, hh:mm:ss, Size (med 'M' for megabyte eller 'G' for gigabyte; f.eks. 200M eller 1G), MyInputFile, MyResultFile og YourCommands.

Arbeidskatalog

Hver jobb har tilgang til et separat scratch område på det delte filsystemet /cluster. Navnet på katalogen er lagret i miljøvariabelen $SCRATCH i jobbskriptet. Som en generell regel bør alle jobber bruke scratch-katalogen ($SCRATCH) som sin arbeidskatalog. Dette er spesielt viktig hvis jobben bruker mange filer, eller har mye "random access" til filene (les og skriv gjentatte ganger til forskjellige steder i filene).

Det er flere gode grunner til å bruke $SCRATCH:

• $SCRATCH er på et raskere filsystem enn brukerens hjemmekatalog.
• Det er mindre risiko for å forstyrre kjørende jobber ved å endre eller slette jobbens inn- eller utdatafiler ved et uhell.
• Midlertidige filer blir automatisk ryddet opp, fordi scratch-katalogen fjernes når jobben er ferdig.
• Man unngår å ta unødvendige sikkerhetskopier av midlertidige og ufullstendige  filer, fordi $SCRATCH ikke er sikkerhetskopiert.

Katalogen der du kjørte sbatch er lagret i miljøvariabelen $SLURM_SUBMIT_DIR. Hvis du ønsker automatisk kopiering av filer eller kataloger tilbake til $SLURM_SUBMIT_DIR når jobben er avsluttet, merk dem med kommandoen chkfile i jobbskriptet:

chkfile OneFile AnotherFile SomeDirectory

• chkfile-kommandoen bør plasseres tidlig i skriptet, før de viktigste beregningskommandoene: Filene vil bli kopiert tilbake selv om skriptet krasjer (selv når du bruker set -o errexit), men ikke hvis det avsluttes før det kom til chkfile kommandoen.
• Hvis du vil bruke skall-metategn, bør de være mellom anførselstegn. Det vil si, bruk chkfile "Results*" i stedet for chkfile Results*.
• Ikke bruk absolutte stier eller ting som ".*" eller .. i kommandoen chkfile; bruk stier som er relative til $SCRATCH.
• Filene/katalogene kopieres til $SLURM_SUBMIT_DIR ved bruk av rsync, som betyr at hvis du bruker chkfile ResultDir, vil innholdet i ResultDir kopieres til $SLURM_SUBMIT_DIR/ResultDir, men hvis du bruker chkfile ResultDir/ (dvs. med en etterfølgende /), vil innholdet i ResultDir vil bli kopiert direkte til $SLURM_SUBMIT_DIR.

Vi anbefaler å bruke chkfile (eller cleanup; se nedenfor) i stedet for å eksplisitt kopiere resultatfilene med cp.

For eksempel:

#!/bin/bash
#SBATCH --job-name=YourJobname --account=YourProject
#SBATCH --time=hh:mm:ss --mem-per-cpu=Size

module purge   # clear any inherited modules
set -o errexit # exit on errors

## Copy files to work directory:
cp YourDatafile $SCRATCH

## Mark outfiles for automatic copying to $SLURM_SUBMIT_DIR:
chkfile YourOutputfile

## Run command
cd $SCRATCH
YourProgram YourDatafile > YourOutputfile

$SCRATCH-katalogen fjernes når jobben avsluttes (etter tilbakekopiering av chkfile-filer).

Hvis du ønsker mer fleksibilitet enn det chkfile gir, kan du bruke kommandoen cleanup i stedet. Den brukes til å spesifisere kommandoer som skal kjøres når jobben avsluttes (før $SCRATCH-katalogen fjernes). Akkurat som chkfile, kjøres cleanup kommandoene selv om skriptet ditt krasjer (selv når du bruker set -o errexit), men ikke hvis det krasjer før cleanup kommandoen nås.  Så plasser kommandoen tidlig i skriptet.

For eksempel:

cleanup "cp $SCRATCH/outputfile /some/other/directory/newName"

Note: ikke bruk enkelt anførselstegn (') hvis kommandoene inneholder variable som $SCRATCH and $SLURM_SUBMIT_DIR.

Dele opp en jobb i oppgaver (Array jobber)

For å kjøre mange forekomster av samme jobb, bruk --array  for å bytte til sbatch. Dette er nyttig hvis du har mange datasett som du vil behandle på samme måte med samme jobbskript:

sbatch --array=from-to [other sbatch switches] YourScript

Du kan også sette --array i en #SBATCH-linje inne i skriptet. from og to er første og siste oppgavenummer. Hver forekomst av YourScript kan bruke miljøvariabelen $SLURM_ARRAY_TASK_ID for å velge hvilket datasett som skal brukes, osv. For eksempel:

sbatch --array=1-100 MyScript

kjører 100 kopier av MyScript, og setter miljøvariabelen $SLURM_ARRAY_TASK_ID til 1, 2, ..., 100 etter tur.

Det er mulig å spesifisere oppgave-ID-ene på andre måter enn from-to: det kan være et enkelt tall, et område ( from-to), et område med en trinnstørrelse (from-to:step), eller en kommaseparert liste av disse. Til slutt, å legge til %max på slutten av spesifikasjonen setter en grense for hvor mange oppgaver som får kjøres samtidig. Et par eksempler:

Specification   Resulting TASK_IDs
1,4,42        # 1, 4, 42
1-5           # 1, 2, 3, 4, 5
0-10:2        # 0, 2, 4, 6, 8, 10
32,56,100-200 # 32, 56, 100, 101, 102, ..., 200
1-200%10      # 1, 2, ..., 200, but maximum 10 running at the same time

Merk: mellomrom, desimaltall eller negative tall er ikke tillatt.

Forekomstene av en array-jobb er uavhengige, de har sin egen $SCRATCH og blir behandlet som separate jobber. (Dette betyr at de teller mot grensen for totalt antall jobber en bruker kan ha i jobbkøen, for tiden 400.) Du kan også spesifisere et parallelt miljø i array-jobs, slik at hver instans får f.eks. 8 prosessorer. For å avbryte alle oppgaver i en array-jobb, avbryt jobb-id som returneres av sbatch-kommandoen.

Se man sbatch for detaljer.

Et utvidet eksempel:

$ cat JobScript
#!/bin/bash
#SBATCH --account=YourProject
#SBATCH --time=1:0:0
#SBATCH --mem-per-cpu=1G
#SBATCH --array=1-200

module purge   # clear any inherited modules
set -o errexit # exit on errors

DATASET=dataset.$SLURM_ARRAY_TASK_ID
OUTFILE=result.$SLURM_ARRAY_TASK_ID

cp $DATASET $SCRATCH
cd $SCRATCH
chkfile $OUTFILE
YourProgram $DATASET > $OUTFILE

$ sbatch JobScript

Denne jobben vil prosessere datasettene dataset.1, dataset.2, ... dataset.200 og  lagre resultatene i result.1, result.2, ... result.200.

Paralelliserte Jobber

Siden klyngene består av multi-cpu og multi-core databehandlingsnoder, er det flere måter å parallellisere kode og kjøre jobber parallelt. Man kan bruke MPI, OpenMP og threading. (For SIMD-jobber og andre jobber med svært uavhengige parallelle oppgaver, er array-jobber et godt alternativ.) I denne delen vil vi forklare hvordan du kan kjøre parallelt på en av disse måtene.

Merk: En parallell jobb vil få en, delt scratch-katalog ($SCRATCH), ikke separate kataloger for hver node! Dette betyr at hvis mer enn én prosess eller tråd skriver ut til disk, må de bruke forskjellige filnavn, eller legge filene i forskjellige underkataloger.

OpenMP eller Threading

For å kjøre parallelt på én node ved å bruke enten threading eller OpenMP, er det eneste du trenger å huske å fortelle køsystemet at oppgaven din trenger mer enn én kjerne, alt på samme node. Dette gjøres med --cpus-per-task. Den vil reservere de nødvendige kjernene på noden og sette miljøvariabelen $OMP_NUM_THREADS. For eksempel:

#!/bin/bash
# Job name:
#SBATCH --job-name=YourJobname
#
# Project:
#SBATCH --account=YourProject
#
# Wall clock limit:
#SBATCH --time=hh:mm:ss
#
# Max memory usage per core (MB):
#SBATCH --mem-per-cpu=MegaBytes
#
# Number of cores:
#SBATCH --cpus-per-task=NumCores

## Set up job environment:
module purge   # clear any inherited modules
set -o errexit # exit on errors

## Copy files to work directory:
cp YourDatafile $SCRATCH

## Mark outfiles for automatic copying to $SLURM_SUBMIT_DIR:
chkfile YourOutputfile

## Run command
cd $SCRATCH
## (For non-OpenMP-programs, you must control the number of threads manually, using $OMP_NUM_THREADS.)
YourCommand YourDatafile > YourOutputfile

--cpus-per-task vil sikre at alle kjerner er allokert på en enkelt node. Hvis du ber om flere kjerner enn det som er tilgjengelig på noen node, vil du ikke kunne sende inn jobben. De fleste noder på Colossus har 64 kjerner.

MPI

For å kjøre MPI-jobber må du spesifisere hvor mange oppgaver som skal kjøres (dvs. kjerner som skal brukes), og sette opp ønsket MPI-miljø. Symbolgenereringen for forskjellige fortran-kompilatorer er forskjellig, derav versjoner av MPI fortran-grensesnittet for GNU, Intel, Portland og Open64. Alle OpenMPI-biblioteker er bygget ved hjelp av gcc.

Du må bruke module load both for å kompilere koden og kjøre den. Du bør også kompilere og kjøre i samme MPI-miljø. Selv om noen MPI-versjoner kan være kompatible, er de vanligvis ikke det.

Hvis du trenger å kompilere C MPI-kode med icc, se OpenMPIs dokumentasjon om miljøvariabler som skal settes for å tvinge mpicc til å bruke icc.

Den enkleste måten å spesifisere antall oppgaver (kjerner) som skal brukes i en MPI-jobb, er å bruke sbatch-bryteren --ntasks. For eksempel

#SBATCH --ntasks 10

vil gi deg 10 oppgaver. Køsystemet tildeler oppgavene til noder avhengig av tilgjengelige kjerner og minne osv. Et enkelt MPI-jobscript kan da være slik:

#!/bin/bash
# Job name:
#SBATCH --job-name=YourJobname
#
# Project:
#SBATCH --account=YourProject
#
# Wall clock limit:
#SBATCH --time=hh:mm:ss
#
# Max memory usage per task:
#SBATCH --mem-per-cpu=Size
#
# Number of tasks (cores):
#SBATCH --ntasks=NumTasks

## Set up job environment:
module purge   # clear any inherited modules
set -o errexit # exit on errors

module load openmpi.gnu

## Set up input and output files:
cp InputFile $SCRATCH
chkfile OutputFile

cd $SCRATCH
srun YourCommand

Køsystemalternativer

Ved å bruke køalternativet --ntasks i det forrige eksempelet, har vi antatt at det ikke spiller noen rolle hvordan oppgavene dine er allokert til noder. Køsystemet vil kjøre oppgavene dine på noder slik det passer (det vil imidlertid prøve å tildele så mange oppgaver som mulig på hver node). For små jobber er dette vanligvis greit. Noen ganger kan du imidlertid trenge mer kontroll. I slike tilfeller kan du bruke bryterne --nodes og --ntasks-per-node i stedet for --ntasks:

• --nodes: Hvor mange noder skal benyttes
• --ntasks-per-node: Hvor mange oppgaver skal kjøres på hver node

For eksempel, for å kjøre 1 oppgave på hver av 4 noder, kan du bruke

#SBATCH --nodes=4 --ntasks-per-node=1

Eller for å kjøre 4 oppgaver på hver av 2 noder:

#SBATCH --nodes=2 --ntasks-per-node=4

There are more advanced options for selecting cores and nodes, as well. See man sbatch for the gory details.

Der er også mer avanserte alternativer for å velge kjerner og noder. Se man sbatch for detaljer.

TCP/IP over InfiniBand for MPI

Hvis du har MPI-jobber som tett knyttet opp mot bruk av TCP/IP, har vi noen knep for å bruke InfiniBand selv for disse. Det er mulig å kjøre TCP/IP over InfiniBand med langt bedre ytelse enn over Ethernet. Dette gjelder imidlertid kun kommunikasjon mellom beregningsnodene. Ta kontakt med oss hvis du har en slik applikasjon eller ønsker å bruke TCP/IP over InfiniBand. Alle noder har to IP-numre ett for Ethernetnet og ett for InfiniBand.

Nyttige kommandoer i MPI script

Hvis du trenger å utføre en kommando én gang på hver node i en jobb, kan du bruke

srun --ntasks=$SLURM_JOB_NUM_NODES command

Kombinasjoner av MPI med OpenMP eller threading

Du kan kombinere MPI med OpenMP eller threading, slik at MPI brukes til å starte flertrådede prosesser på hver node. Den beste måten å gjøre dette på er:

#!/bin/bash
# Job name:
#SBATCH --job-name=YourJobname
#
# Project:
#SBATCH --account=YourProject
#
# Wall clock limit:
#SBATCH --time=hh:mm:ss
#
# Max memory usage per task:
#SBATCH --mem-per-cpu=Size
#
# Number of tasks (MPI ranks):
#SBATCH --ntasks=NumTasks
#
# Number of threads per task:
#SBATCH --cpus-per-task=NumThreads

## Set up job environment:
module purge   # clear any inherited modules
set -o errexit # exit on errors
module load openmpi.gnu

## Set up input/output files:
cp InputFile $SCRATCH
chkfile OutputFile

## Run command
## (If YourCommand is not OpenMP, use $OMP_NUM_THREADS to control the number of threads manually.)
srun YourCommand

Dette får srun til å starte NumTasks "ranks" (prosesser), som hver har NumThreads tråder. Hvis du ikke bruker OpenMP, må programmet passe på å ikke starte mer enn NumThreads tråder.

Akkurat som med entrådede MPI-jobber, kan du få mer enn én "rank" (MPI-prosess) på hver node. Hvis du trenger mer kontroll over hvor mange "ranks" som startes på hver node, bruk --ntasks-per-node og --nodes som ovenfor. For eksempel:

#SBATCH --nodes=3 --ntasks-per-node=2 --cpus-per-task=4

vil starte 2 MPI "ranks" på hver av 3 noder, og hver prosess har lov til å bruke 4 tråder.

Jobber som krever store mengder minne

De fleste noder på Colossus er utstyrt med 64 CPU-kjerner og 502 GiB RAM tilgjengelig for jobber. Det finnes også et par spesielle bigmem-noder med 128 kjerner og 4 TiB-minne, hvorav ca 3955 GiB kan brukes til jobber.

Hvis du trenger mer enn 502 GiB RAM på en enkelt node, må du spesifisere  --partition=bigmem for å få tilgang til nodene med mer RAM. For eksempel

#SBATCH --ntasks-per-node=16
#SBATCH --mem-per-cpu=50G --partition=bigmem

Regnskap for "hugemem" jobber

For å sikre maksimal utnyttelse av klyngen, tas minnebruk inn i regnskapet så vel som cpu-bruk. Minnespesifikasjoner konverteres til "Processor Equivalents" (PE) ved å bruke en konverteringsfaktor på ca. 8 GiB/kjerne(*). Hvis en jobb spesifiserer mer enn 8 GiB RAM per oppgave, dvs. --mem-per-cpu=M, hvor M > 8G, vil hver oppgave telle som M / 8G kjerner i stedet for 1 kjerne. For eksempel vil en jobb med --ntasks=2 --mem-per-cpu=16G bli regnet som å bruke 4 kjerner i stedet for 2.

Grunnen til dette er at store minnejobber gjør de «ubrukte» kjernene på de samme nodene utilgjengelige for andre jobber. For eksempel vil en jobb på en 502 GiB node som bruker --ntasks=1 --mem-per-cpu=502G i praksis bruke alle kjerner på noden, og bør regnskapsføres som sådan.

Merk at kun jobber som spesifiserer mer enn 8 GiB per kjerne vil bli påvirket av dette; alle andre jobber vil bli regnskapsført med antall "tasks".

(*) Den nøyaktige verdien av faktoren avhenger av den totale mengden RAM per kjerne i klyngen, og er for øyeblikket omtrent 8 GiB / kjerne på Colossus.

GPU jobber

Colossus har 4 GPU-noder med 2 Nvidia Tesla V100 GPUer hver. To er tilgjengelige for alle brukere og 2 er reservert for dedikerte prosjekter. Du kan kjøre jobber på GPU-nodene slik:

 $ sbatch --account=YourProject_tsd --partition=accel --gres=gpu:1

eller

 $ sbatch --account=YourProject_tsd --partition=accel --gres=gpu:2

avhengig av hvor mange GPUer jobben trenger.

Checkpointing

"Checkpointing" av en jobb betyr at jobben kan stoppes og så startes et annet sted, og fortsette der den slapp.

Langvarige jobber bør implementere en form for "checkpointing", ved å lagre mellomresultater med jevne mellomrom slik at det blir mulig å starte med de siste mellomresultatene hvis jobben startes på nytt.

Nyttige sbatch parametre

Parameter	Beskrivelse
--account=project	Spesifiser prosjektet som jobben kjøres under. Denne parameteren er påkrevd.
--begin=time	Start jobben på et gitt tidspunkt
--constraint=feature	Be om noder med en bestemt funksjon. For øyeblikket støttede funksjoner inkluderer amd, intel, ib, rackN. Hvis du trenger mer enn én funksjon, må de kombineres med & i samme --constraint spesifikasjon, f.eks. --constraint=ib&rack21. Merk: Hvis du prøver å bruke mer enn én --constraint spesifikasjon, vil den siste overstyre den tidligere.
--cpus-per-task=cores	Spesifiser antall CPUer (faktisk: kjerner) som skal tildeles for hver oppgave i jobben. Se --ntasks og -ntasks-per-node, eller man sbatch.
--dependency=dependency list	Utsett starten av denne jobben til de spesifiserte avhengighetene er tilfredsstilt. Se man sbatch for detaljer.
--error=file	Send 'stderr' til den angitte filen. Standard er å sende den til samme fil som 'stdout'. (Merk: $HOME eller ~ kan ikke brukes. Bruk absolutte eller relative stier i stedet.)
--input=file	Les 'stdin' fra den angitte filen. (Merk: $HOME eller ~ kan ikke brukes. Bruk absolutte eller relative stier i stedet.)
--job-name=jobname	Spesifiser jobb navn
--mem-per-cpu=size	Spesifiser mengden minne som kreves per tildelt kjerne. Dette er den normale måten å spesifisere minnekrav på (se Jobber som krever store mengder minnne). size skal være et heltall etterfulgt av "M" eller "G".
--partition=bigmem	Kjør jobben på en bigmem node (se Jobber som krever store mengder minnne).
--nodes=nodes	Spesifiser antall noder som skal tildeles. nodes kan være et heltall eller et område (min-maks). Dette kombineres ofte med --ntasks-per-node.
--ntasks=tasks	Spesifiser antall oppgaver (vanligvis kjerner, men se --cpus-per-task) som skal tildeles. Dette er den vanlige måten å spesifisere kjerner på for MPI-jobber.
--ntasks-per-node=tasks	Spesifiser antall oppgaver (vanligvis kjerner, men se --cpus-per-task) som skal tildeles innenfor hver tildelt node. Ofte kombinert med --nodes.
--output=file	Send 'stdout' (and 'stderr' if not redirected with --error) to the specified file instead of slurm-%j.out. Send 'stdout' (og 'stderr' hvis ikke omdirigert med --error) til den angitte filen i stedet for slurm-%j.out. Merk: $HOME eller ~ kan ikke brukes. Bruk absolutte eller relative stier i stedet. Jobb-id skal alltid inkluderes i filnavnet for å produsere en separat fil for hver jobb (dvs. --output=custom-name%j.out). Dette er nødvendig for feilsøking.
--time=time	Angi en ("wall clock") tidsbegrensning for jobben. time kan være hh:mm:ss eller dd-hh:mm:ss. Denne parameteren er påkrevd.
--nice=value	Kjør jobben med en justert planleggingsprioritet i prosjektet ditt. En negativ "nice" verdi øker prioriteten, ellers reduserer den. Justeringsområdet er +/- 2147483645.