FAQs zum Batchsystem

Nur mit diesen Pflichtangaben kann der Scheduler entscheiden, auf welchen Compute-Knoten er den Benutzerjob zur Ausführung bringt.

Wenn man z.B. kein --mem-per-cpu= angibt, würde ein Job mit sehr großen Hautspeicheranforderungen u.U. auf einem Knoten mit zu wenig RAM ausgeführt werden und abstürzen.

Um es „spielerisch“ auszudrücken: mit den Ressourcenanforderungen aller im Batchsystem eingestellten Jobs muss der Scheduler eine Art „multidimensionales Tetris“ spielen, um die Jobs mindestens nach den Dimensionen Laufzeit, Hauptspeicherbedarf und CPU-Core-Anzahl möglichst effizient im Cluster zu plazieren. (Im Hintergrund spielen noch viele andere Parameter als diese drei eine Rolle.)

Mindestens diese drei muss man also angeben, um dem Scheduler etwas zum Verteilen an die Hand zu geben.

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üßten.

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 haben.

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.

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 realem 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 …
cp resultfile $HOME/jobresults/

Jetzt bestimmt das Ergebnis des „cp“-Befehls den exit code des gesamten Jobscripts, weil es sein letztes Kommando ist. Klappt der Kopierbefehl, wird Slurm den Job als COMPLETED bezeichnen, 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=$?
cp resultfile $HOME/jobresults/
/any/other/job/closure/cleanup/commands …
echo Job finished at $(/bin/date +%FT%R)
exit $EXITCODE

Jetzt wird der exit code von „myScientificProgram“ in der Variablen $EXITCODE zwischengespeichert. Trotz der darauffolgenden Kommandos kann man das Jobscript via exit-Befehl nun mit dem „echten“, wichtigen exit code der eigentlichen wiss. Berechnung beenden.

Somit erhält Slurm jetzt diesen exit code der wiss. Berechnung (statt den des zufällig letzten Kommandos im jobscript) und wird nur noch solche Jobs als COMPLETED betrachten, bei denen „myScientificProgram“ fehlerfrei durchgelaufen ist.

Wir überarbeiten diese Seite von Zeit zu Zeit.

Bitte senden Sie uns Ihre Frage als email an . Dann können wir sie beantworten und gegebenenfalls hier aufnehmen.