FAQs Batchsystem

Jobs vorbereiten

Ja, das geht mit dem Parameter „--test-only“ bei „sbatch“:

sbatch --test-only submit_tests
[E] sbatch: Job 12…78 to start at yyyy-mm-ddThh:mm:ss using XX processors on nodes mpsc[000y-000z] in partition P

Antwortet das System mit solch einer Meldung, würde Slurm diesen Job so annehmen und voraussichtlich zu der (geschätzten!) Zeit anlaufen lassen.

Obwohl das System auch diese Meldung scheinbar als Fehler klassifiziert („[E] …“), ist bei obiger Ausgabe kein echter Fehler aufgetreten.

Sollten Sie aber z.B. einen erforderlichen Parameter vergessen haben, sähe die Ausgabe zum Beispiel in etwa so aus:

[E] Missing runlimit specification – Use --time=<[hh:]mm>

Wenn sich sbatch <jobscript> über fehlende Angaben beschwert, obwohl Sie genau diese in Form von Pragmas

#SBATCH …

definiert haben, kann das an Windows-Zeilenenden liegen, die von UNIX/Linux nicht als gültig erkannt werden.

Wenn Sie das fragliche Jobscript auf Ihrem Windows-PC erzeugt und per scp auf einen Loginnode übertragen haben, wandeln Sie es einfach per

dos2unix jobscriptfile

in ein UNIX/Linux-File um.

Sollten die obigen Fehler dann immer noch auftreten, überprüfen Sie die Minus- bzw. Bindestrich-Zeichen „-“. Hier können sich Gedanken- oder Geviertstriche eingeschlichen haben, die nicht als Parameter-Einleitungszeichen wirken können.

Bevor Sie Jobs abschicken, müssen Sie ermitteln, wieviele CPUs (= Kerne) Sie am besten nutzen, wieviel Hauptspeicher Ihr wissenschaftliches Programm benötigen wird und wie lange es für die Berechnungen mindestens laufen muss.

Falls Ihr wissenschaftliches Programm und vergleichbare Probleme in Ihrer Arbeitsgruppe bereits bearbeitet werden, erkundigen Sie sich bei Ihren Kollegen nach deren Erfahrungen damit.

Falls Sie mit neuem Programm oder neuem Problem starten: bereiten Sie sich einen vergleichsweise kleinen Testfall vor (nicht mehr als 30 Minuten Laufzeit) und lassen Sie ihn auf einem der Login-Knoten mit der gewünschten Anzahl CPU-Kernen unter der Kontrolle des UNIX-„time“-Kommandos laufen:

/bin/time --format='MaxMem: %Mkb, WCT: %E' myProgram <testcase>

Danach erhalten Sie auf dem STDERR -Kanal zum Beispiel die Ausgabe

MaxMem: 942080kb, WCT: 1:16.00

Nach Umrechnung von „MaxMem“ in MBytes (durch 1024 dividieren) können Sie Ihren #SBATCH --mem-per-cpu=-Parameter für diesen Testlauf wie folgt errechnen:

MaxMem in MByte
--------------------- (zuzüglich Sicherheitspuffer)
# der Prozessorkerne

Ihre maximal benötigte Laufzeit ( #SBATCH -t d-hh:mm:ss im Jobscript) ist dann die obige WCT" (wiederum zzgl. Sicherheitszuschlag).

In unserem Beispiel und falls Sie 4 Prozessorkerne benutzt haben:

 942080 / 1024 / 4 =
--mem-per-cpu=230

Wenn Sie Ihren Testfall mit jeweils 2, 4, 8 und 16 Prozessorkernen laufen lassen, bekommen Sie einen groben Eindruck von der Skalierbarkeit Ihres Problems, und können die für Ihre echten Jobs nötige Laufzeit und den Hauptspeicherbedarf besser abschätzen.

In Kürze und hierarchisch dargestellt: der Lichtenberg-Cluster besteht aus

Rechenknoten
einzelne, unabhängige Rechner vergleichbar einem PC/Laptop (nur mit mehr und leistungsfähigerer Hardware)
Ein Rechenknoten besteht aus
- zwei oder mehr CPUs (central processing units oder Prozessoren), die je in einem eigenen „socket“ stecken.
  CPUs sind die eigentlichen „programmausführenden“ Komponenten eines Knotens.
  Eine CPU besteht aus
  - mehreren Kernen, die man als separate Ausführungseinheiten innerhalb einer CPU verstehen kann.
    Je mehr Kerne, desto mehr unabhängige Prozesse bzw. Ausführungsstränge (threads) können gleichzeitig ausgeführt werden.
    Jeder Kern kann entweder von
    - einem Prozess bzw. Task (MPI)
      oder
    - einem Ausführungsstrang (thread) benutzt werden
      Solch „Multithreading“ kann z.B. mit POSIX-Threads oder heutzutage meistens OpenMP (Open MultiProcessing) umgesetzt sein.

Eine reine MPI-Applikation würde also so viele verschiedene Prozesse (= Tasks) starten wie insgesamt an Rechenkernen (cores) angefordert wurden. Diese Prozesse kommunizieren dann miteinander über MPI.

Die Prozesse eines MPI-Jobs können auch über mehrere Rechenknoten verteilt laufen, wobei die MPI-Transfers dann über Infiniband gehen.

Eine reine Multithreaded-Applikation hingegen startet nur einen Prozess, der sich dann selbst in mehrere unabhängige Ausführungsstränge aufspaltet. Jeder dieser Threads hat im Optimalfall einen einzelnen Kern zur Verfügung, so dass ein einziger Prozess viele Kerne gleichzeitig nutzen kann.

Die heute üblichen Programme nutzen dazu meist OpenMP (siehe $OMP_NUM_THREADS in der Dokumentation Ihres Programms).

Solche Applikationen können nicht über mehrere Knoten verteilt rechnen, dafür aber alle Kerne eines Rechenknotens im selben Programm nutzen.

Hybride Applikationen kombinieren beide Parallelisierungsverfahren: pro verfügbarem Rechenknoten starten sie z.B. nur einen Prozess (= Task), der dann wiederum die auf jedem einzelnen Knoten verfügbaren Kerne mittels Threads ausnutzt. Die Threads kommunizieren verzögerungsfrei über ihren gemeinsamen Hauptspeicher innerhalb eines Knotens, während die Prozesse wiederum mittels MPI die Knotengrenzen überwinden.

.

Wichtig in diesem Zusammenhang:

Aus historischen Gründen (aus der Ära vor den heutigen Mehrkern-CPUs) hat SLURM Parameter, die scheinbar auf CPUs zugeschnitten sind (.z.B.. --mem-per-cpu=).

Heutzutage meint das jedoch immer Kerne statt CPUs! Das mag verwirrend sein, aber die Regel ist einfach: benutzen und berechnen Sie Ihre „--mem-per-cpu“-Werte einfach so, als hieße der Parameter „--mem-per-core“.

Für sehr viele ähnliche Jobs raten wir dringend davon ab, Shellscript-Schleifen um „sbatch / squeue“ herum zu basteln. Nutzen Sie für >20 Jobs stattdessen einfach Job Arrays in Slurm.

Dieses Vorgehen entlastet nicht nur den Slurm-Scheduler bei seiner Arbeit, sondern Sie können auch wesentlich mehr Array-Tasks submittieren als Einzeljobs!

Beispiele für Anwendungsfälle sind:

dasselbe Programm, dieselben Parameter, aber wechselnde Input-Daten
dasselbe Programm, dieselben Input-Daten, aber jeweils verschiedene Parameter-Sets
nicht-parallelisiertes Programm (das also nicht mehrere Cores [Multi-Threading] oder gar mehrere Nodes [MPI] nutzen kann), das große Mengen an separaten Input-Daten bearbeiten soll, wobei kein Einzellauf von Ergebnissen eines anderen abhängt (z.B. Einzelbildanalyse), auch High-Throughput Computing genannt

Benennen Sie die jeweils „zahlreichen“ Bestandteile mit durchgehender Numerierung: image1.png, image2.png oder paramFile1.conf, paramFile2.conf etc.

Haben Sie z.B. 3124 Sets, setzen Sie ein Jobscript mit

_______________

#SBATCH -a 1-3124
myProgram image$SLURM_ARRAY_TASK_ID.png > image$SLURM_ARRAY_TASK_ID.png.out

_______________

auf und submittieren Sie es. Slurm startet jetzt einen einzigen Job mit 3124 ArrayTasks, die jeweils ihre eigene Bilddatei analysieren und das Ergebnis in jeweils ihre eigene Ausgabedatei schreiben.

Auch für die mittels „-o“ und „-e“ spezifizierten Ausgabe- und Fehlerdateien können Sie "%. -Platzhalter nutzen:

#SBATCH -o /path/to/my/dir/out_%A_%a.txt
#SBATCH -e /path/to/my/dir/err_%A_%a.txt

^{%A = $SLURM_ARRAY_JOB_ID (die „obere“, gemeinsame Job-ID – identisch für alle ArrayTasks)}
^{%a = $SLURM_ARRAY_TASK_ID (die unterschiedliche, hochzählende Nummer jeder einzelnen ArrayTask)}

Wenn Sie die Anzahl gleichzeitig laufender ArrayTasks limitieren müssen, nutzen Sie

#SBATCH -a 1-3124%10

Dann lässt Slurm höchstens 10 Tasks gleichzeitig laufen.

Weitere Details finden Sie in 'man sbatch' unter „--array=“., oder auf der Slurm-Website .

Den meisten wissenschaftlichen Programmen kann man die Zahl der zu nutzenden CPU-Kerne bzw. GPUs als Parameter mitteilen.

Anstatt nun jedesmal sowohl die „#SBATCH …“-Anforderungszeilen als auch die Kommandozeile Ihres Programms ändern zu müssen, können Sie Slurm-Variablen nutzen. Diese werden zum Zeitpunkt der Job-Allokation (Start) gesetzt und stehen im Script zur Verfügung.

Wenn Ihr Programm zum Beispiel MultiThreading in Form von OpenMP nutzt, können Sie Ihr Job-Skript folgendermassen vereinfachen:

#!/bin/bash

…

#SBATCH -c ##

export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK

/Pfad/zu/meinem/wissenschaftlichenProgramm …

Es wird dann immer genau die Anzahl an CPU-Kernen nutzen, die Sie mit „-c ##“ angefordert haben.

Gleiches gilt für GPUs. Wenn die Dokumentation Ihres Programms beispielsweise angibt, dass die Zahl der zu nutzenden GPU-Karten mit dem Parameter „--num-devices=#“ anzugeben ist:

#!/bin/bash

…

#SBATCH --gres=#

/Pfad/zu/meinem/wissenschaftlichenProgramm --num-devices=$SLURM_GPUS_ON_NODE …

Auf diese Weise müssen Sie nur die #SBATCH-Zeilen mit „-c ##“ bzw. „--gres=#“ anpassen, und Ihre Programme laufen automatisch immer mit den tatsächlich angeforderten Ressourcen.

_{(Bitte übernehmen Sie das # nicht direkt in Ihre Scripts – ersetzen Sie es durch die gewünschte Zahl der Kerne/GPUs.)}

Hier können Sie die „--multi-prog“-Option von srun nutzen – damit werden in einer einzigen Allocation (=Job) verschiedene Programme gestartet.

 #!/bin/bash

 #SBATCH …

 srun … --multi-prog myCtrlWorker.conf

Die Datei myCtrlWorker.conf ist nach dem Schema

 Nr /path/to/program <parameter>

aufgebaut, und enthält pro Zeile die Definition, welcher MPI-Rank („Nr“ ⇦ #SBATCH --ntasks=XX) was genau mittels srun und mit welchen Parametern starten soll.

Sollten die „Worker“-Instanzen einen Parameter für ihre jeweils eigene „Nummer“ verlangen, können Sie dort die Platzhalter „%t“ bzw. „%o“ verwenden (siehe ' man srun' unter MULTIPLE PROGRAM CONFIGURATION).

Beispiel

… für einen Controller, der 24 Worker ansteuert:

 # MPI rank, then path to binary

 1 /path/to/controller_program <parameter for controller>

 2-25 /path/to/worker_program <parameter for worker, z.B. WorkerID=%o>

Hier wird srun also zuerst (1) den Controller starten, danach 24 einzelne (2-25) „Worker“-Instanzen, die ihre jeweilige Nummer durch %o erfahren.

Beispiel

… für beliebig viele Worker (Anzahl nur bestimmt durch #SBATCH --ntasks=XX):

 # MPI rank, then path to binary

 1 /path/to/controller_program <parameter for controller>

 * /path/to/worker_program <parameter for worker, z.B. WorkerID=%o>

Der Stern * steht hier für „alle weiteren Ranks“ (ab 2 aufwärts).

Wie genau Controller- und Worker-Prozesse dann im Hauptspeicher „zueinander finden“ bzw. welche Parameter dazu nötig sind, entnehmen Sie bitte der Programm-Dokumentation.

Wartende Jobs

Laufende Jobs

Prüfen Sie das Vorhandensein von allen Verzeichnissen, die Ihr Jobscript angibt, und ob Sie dort schreibberechtigt sind.

Insbesondere das Verzeichnis, das Sie mit

#SBATCH -e /path/to/error/directory/%j.err

spezifizieren, muss bereits vor Anlaufen des Jobs existieren und für Sie beschreibbar sein.

Slurm bricht Ihren Job sofort und kommentarlos ab, wenn es wegen eines fehlenden Verzeichnisses die Output- und Error-Dateien nicht schreiben kann.

Ein Konstrukt innerhalb des Jobscripts wie

#SBATCH -e /path/to/error/directory/%j.err
mkdir -p /path/to/error/directory/

ist ein „Henne und Ei“-Problem und kann daher auch nicht funktionieren: für Slurm ist der „mkdir“-Befehl ja Bestandteil des Jobs, dessen eventuelle Ausgaben (STDOUT oder STDERR ) in das noch nicht existierende Verzeichnis geschrieben werden müssten.

Stellen Sie sicher, dass alle relevanten Module in Ihrem Jobscript geladen werden.

Sie können die nötigen Module zwar nach dem Login direkt auf dem Loginknoten laden, weil diese dann von „sbatch myJobScript“ an den Job „vererbt“ werden, aber das ist nicht zuverlässig.
Stattdessen macht es Ihre Jobs von den in der Login-Umgebung geladenen Modulen abhängig.

Darum empfehlen wir, jedes Jobscript mit

module purge
module load <each and every relevant module>

zu beginnen, um genau die (und nur die) Module zu laden, die Ihr wissenschaftliches Programm benötigt.

Das erleichtert auch die spätere Reproduzierbarkeit Ihrer Jobs, ganz unabhängig von dem Modulset, was Sie damals in Ihrer Login-Session geladen hatten.

Dieses Verhalten kann auftreten, wenn der Job mehrfache verschachtelte Aufrufe von srun (oder mpirun) enthält. Der zweite („innere“) Aufruf versucht dann, dieselben Ressourcen zu allozieren wie der erste („äußere“), und das kann nicht gehen.

1. Script statt ausführbares Programm:

Wenn in Ihrem Jobscript

srun /path/to/myScientificProgram

steht, prüfen Sie, ob „/path/to/myScientificProgram“ nicht vielleicht ein Script ist, das selbst wiederum srun (oder mpirun) aufruft.

In diesem Fall entfernen Sie einfach das srun vor /path/to/myScientificProgram.

2. Allokation per #SBATCH und per 'srun':

Eine solche unabsichtliche „Verschachtelung“ ist auch ein Jobscript mit zwei Allokationen: die „äußere“ per #SBATCH -n 16 und die „innere“ mit srun -n 16:

#SBATCH -n 16

…

srun -n 16 … /path/to/myScientificProgram

Lassen Sie hier einfach das „-n 16“ bei 'srun' weg, denn der Vorteil von srun gegenüber mpirun ist ja gerade, dass srun von Slurm alles über den Job weiß und „erbt“.

Beispiel-Fehler:

srun: Job XXX step creation temporarily disabled, retrying
srun: error: Unable to create step for job XXX: Job/step already completing or completed
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
slurmstepd: error: *** STEP XXX.0 ON hpb0560 CANCELLED AT 2020-01-08T14:53:33 DUE TO TIME LIMIT ***
slurmstepd: error: *** JOB XXX ON hpb0560 CANCELLED AT 2020-01-08T14:53:33 DUE TO TIME LIMIT ***

OpenMPI hat unter SLURM die Einschränkung, dass genau diese Routine MPI_Comm_spawn() zum späteren Nachstarten von MPI-Ranks nicht funktioniert.

Wenn Ihr Programm dieses Feature unbedingt nutzen muss, bleibt nur der Wechsel zu einer anderen MPI-Implementierung wie z.B. „intelmpi“ übrig.

Beispielfehler:

[mpsc0111:1840264] *** An error occurred in MPI_Comm_spawn

[mpsc0111:1840264] *** reported by process [2377252864,38]

[mpsc0111:1840264] *** on communicator MPI_COMM_SELF

[mpsc0111:1840264] *** MPI_ERR_SPAWN: could not spawn processes

[mpsc0111:1840264] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,

[mpsc0111:1840264] *** and potentially your MPI job)

Slurm kann nicht erkennen, welches der Kommandos in einem Job (script) wirklich „wichtig“ ist. Der einzige Mechanismus zur Feststellung von Erfolg oder Fehler ist der exit code Ihres Jobscripts, nicht der „echte“ Verlauf Ihres wissenschaftlichen Programms.

Programme, die sich an gängige Programmierkonventionen halten, beenden sich mit einem exit code von 0, wenn alles geklappt hat, und >0 im Fehlerfall.

Der exit code eines Skripts ist der seines letzten Kommandos.

Im folgenden Beispiel

#!/bin/bash
#SBATCH …
myScientificProgram …

ist das zuletzt ausgeführte Kommando wirklich das wissenschaftliche Programm, und damit endet das gesamte Jobscript wie gewünscht auch mit dessen exit code. Slurm wird den Job nun als COMPLETED behandeln, wenn „myScientificProgram“ mit 0 geendet hat, und als FAILED, falls nicht.

Fügt man nun aber irgendwelche anderen Kommandos (zum Aufräumen oder Resultate-Kopieren) nach „myScientificProgram“ ein, überschreiben diese den exit code des eigentlichen Programms:

#!/bin/bash
#SBATCH …
myScientificProgram …
echo „Job beendet“

Jetzt bestimmt das Ergebnis des „echo“-Befehls den exit code des gesamten Jobscripts, weil es sein letztes Kommando ist. Klappt der „echo“-Befehl (und das tut er fast immer), wird Slurm den Job als COMPLETED betrachten und so vermelden, obwohl „myScientificProgram“ eine Zeile vorher komplett fehlgeschlagen sein könnte.

Um das zu vermeiden (und trotzdem nach der eigentlichen wiss. Rechnung noch Kommandos auszuführen), muss man den „wichtigen“ exit code vor den nächsten Kommandos zwischenspeichern:

#!/bin/bash
#SBATCH …
myScientificProgram …
EXITCODE=$?
/any/other/job/closure/cleanup/commands …
echo „Job beendet“
exit $EXITCODE

Hier wird der exit code von „myScientificProgram“ in der Variablen $EXITCODE zwischengespeichert. Trotz der darauffolgenden Kommandos kann man das Jobscript nun via exit-Befehl mit dem „echten“ exit code beenden, der Ihnen wichtig ist.

Dadurch empfängt Slurm jetzt den exit code der wiss. Berechnung (statt den des zufällig letzten Kommandos im Jobscript) und wird nur noch solche Jobs als COMPLETED vermelden, bei denen „myScientificProgram“ fehlerfrei durchgelaufen ist.

Wenn Sie für jeden Job wissen wollen, wann genau er startet und endet, können Sie dies mit je einer einzigen Zeile in den STDERR -Kanal schreiben lassen (den die mit „#SBATCH -e …“ angegebene Datei aufzeichnet):

-----------------------

#SBATCH …
/usr/bin/date +„Job ${SLURM_JOBID} START: %F_%T.%3N“ >&2
module purge
module load module1 module2 module3
/path/to/my/scientific/program …
EXITCODE=$?
/usr/bin/date +„Job ${SLURM_JOBID} END: %F_%T.%3N“ >&2
exit ${EXITCODE}

-----------------------

Ohne extra Zeilen mit „echo“ o.ä. gibt Ihnen jetzt das „date“-Kommando die exakten Zeiten aus, und Sie haben immer die genaue Laufzeit Ihrer „Payload“.

^{Zu den mit % spezifizierten Platzhaltern für die Datums- und Zeitangaben konsultieren Sie einfach 'man date' unter „FORMAT controls“.}

Sonstiges

Wenn Sie per Mail über Statusänderungen Ihrer Jobs benachrichtigt werden wollen, schreiben Sie in Ihrem Job-Skript

#SBATCH --mail-type=…

und setzen den Parameter … auf BEGIN oder END oder FAIL oder ALL, und der Scheduler wird die entsprechenden Mails an Sie versenden.

Da alle Jobs immer mit Ihrem Login-Namen – also Ihrer TU-ID – verknüpft sind, haben wir Slurm so eingestellt, dass es automatisch die zu Ihrer TU-ID gehörige eMail-Adresse verwendet. Diese wird nicht bei uns gespeichert, sondern immer aktuell aus dem IDM-System der TU abgefragt.

Ändern Sie also die Mailadresse Ihrer TU-ID, gehen die nächsten Scheduler-Mails sofort an das dort (neu) eingestellte Ziel.

FAQ zum Batchsystem

Häufig gestellte Fragen zum Batchsystem

Jobs vorbereiten

Wartende Jobs

Laufende Jobs

Sonstiges