Auf dem OMNI-Cluster ist der Job Scheduler SLURM in der Version 22.05.8 installiert. SLURM dient dazu, die Rechenjobs der Nutzer so auf dem Cluster zu verteilen, dass dieser möglichst effizient genutzt wird und die Wartezeiten so kurz wie möglich sind. Mehr Informationen zum Einstellen von Jobs finden Sie hier. Die SLURM-Dokumentation befindet sich hier.

Tipp: SLURM steht nur zur Verfügung, wenn das SLURM-Modul auch geladen ist (module load slurm). Standardmäßig wird das SLURM-Modul beim Login immer geladen, es kann aber durch Nutzeraktionen versehentlich oder absichtlich entladen werden (z.B. mit module purge). Wenn Sie die SLURM-Befehle nicht zur Verfügung haben, vergewissern Sie sich mit module list, dass das Modul geladen ist. Weitere Informationen zu Module finden Sie hier.

Ein SLURM-Job bezieht seine Einstellungen aus verschiedenen Quellen. In absteigender Reihenfolge der Priorität sind dies:

  • Kommandozeilenparameter des Befehls, mit dem der Job eingestellt wurde.
  • Umgebungsvariablen, falls gesetzt.
  • Die Parameter am Anfang eines Jobskripts, falls angegeben.
  • Die in SLURM eingestellten Standards.

Das heißt zum Beispiel, dass Sie in einem Job-Skript spezifizieren können, mit welchen Einstellungen es laufen soll, und wenn Sie einmalig abweichende Einstellungen benötigen, können Sie beim Aufruf einfach einen Kommandozeilenparameter angeben.

SLURM-Begriffe

SLURM kennt und berücksichtigt im Prinzip die Aufteilung des Clusters in Knoten mit einzelnen Kernen. Bei der Einstellung von Jobs gibt es mehrere Möglichkeiten, Ressourcen anzufordern. In SLURM-Terminologie ist:

  • Ein Job eine in sich abgeschlossene Rechnung, die aus mehreren Tasks bestehen kann und bestimmte Ressourcen wie einzelne CPU-Kerne, eine bestimmte Menge Arbeitsspeicher oder komplette Knoten zugewiesen (allokiert) bekommt.

  • Ein Task der Lauf eines einzelnen Prozesses. Standardmäßig wird pro Knoten ein Task gestartet, und pro Task eine CPU zugewiesen.

  • Eine Partition (häufig auch Queue genannt) eine Warteschlange, in der Jobs eingestellt werden.

  • Eine CPU in Slurm bezeichnet einen einzelnen Kern. Dies ist abweichend von der üblichen Terminologie, in der eine CPU (ein Mikroprozessor-Chip) aus mehreren Kernen besteht. Slurm spricht von “Sockets”, wenn CPU-Chips gemeint sind.

Konsolenbefehle und Optionen

Hier sind die üblichsten Befehle, die Sie als SLURM-Nutzer benötigen.

Befehl Funktion
squeue Jobs anzeigen.
sinfo Informationen zu belegten und freien Knoten anzeigen.
sbatch Stellt einen Batch-Job ein.
srun Außerhalb eines Jobs: stellt einen Job mit einem Linux-Befehl ein. Innerhalb eines Jobs: führt einen Befehl in jedem Task aus.
spartition Informationen zu den Partitionen (Queues) anzeigen. ZIMT-Addition.
scancel Einen Job löschen.
sview Grafische Oberfläche starten.
scontrol Detailliertere Informationen (nicht alle für normale Nutzer verfügbar).

Viele dieser Befehle haben Optionen (Kommandozeilenparameter), die Sie beim Aufruf mit angeben können. Die wichtigsten sind hier kurz aufgelistet:

Option Funktion OMNI
--partition, -p Definiert die Partition auf welcher der Job laufen soll. spartition zeigt die zur Verfügung stehenden Partitionen.
--nodes, -N Definiert die Anzahl der Knoten, auf denen der Job laufen soll. 1 (oder mehr für MPI-Anwendungen)
--ntasks, -n Definiert die Anzahl der Tasks für den Job. 1-64 (anhängig vom Anwendungsfall)
--ntasks-per-node Definiert die maximale Anzahl der Tasks pro Knoten. Wird in der Regel mit MPI-Programmen benutzt.
--cpus-per-task Definiert die Anzahl der CPUs pro Task. In der Regel bei Verwendung von OpenMP wichtig.
--mem Definiert das Arbeitsspeicher-Limit pro Knoten. Der Job wird abgebrochen, sollte das Limit überschritten werden (kein Swapping). Der Zahlenwert ist in Megabyte. Default: 3750MB, max. 240GB (hpc-node) und 480GB (fat-node), Bitte sparsam einsetzen. Für Anwendungen mit besonders hohem Speicherbedarf können die Knoten der smp-Partition mit je 1530GB RAM genutzt werden.
--time, -t Definiert das Zeitlimit des Jobs. Wird das Limit überschritten, wird der Job abgebrochen. Format: D-HH:MM:SS spartition zeigt die default und min/max Laufzeiten der verschiedenen Partitionen.
--gpus, -G Anzahl der GPUs, die zu benutzen sind. Analog: --gres=gpu:X wobei X die Anzahl der GPUs ist. Beachten Sie, dass der OMNI-Cluster Knoten mit verschieden vielen GPUs hat.
--output=<Dateiname> Beim sbatch-Befehl spezifiziert dies die Log-Datei in welcher der stdout-Stream geleitet wird. Standardmäßig wird im Ordner, in dem sbatch ausgeführt wurde, eine Datei namens slurm-<JobID>.out angelegt.
--error=<Dateiname> Beim sbatch-Befehl spezifiziert dies die Log-Datei in welcher der stderr-Stream geleitet wird. Standardmäßig wird stderr an dieselbe Stelle geschrieben wie stdout, siehe oben.
--mail-type Spezifiziert die Ereignisse, bei denen eine E-Mail an die mit --mail-user spezifizierte Adresse versendet werden soll. Mögliche Angaben sind BEGIN, END, FAIL, REQUEUE, ALL.
--mail-user=<Adresse> Spezifiziert den Empfänger der E-Mail.
--no-requeue Deaktiviert das automatische Neustarten einen Jobs. Default: Requeue=1 (--requeue)

Eine volle Liste finden Sie für jeden Befehl mittels man <Befehlsname> oder <Befehlsname> --help und auch in der SLURM-Dokumentation von sbatch.

Umgebungsvariablen

SLURM verwendet eine Reihe von Umgebungsvariablen. Einige können Sie benutzen, um SLURM-Jobs Einstellungen mitzugeben (es sei denn Sie überschreiben sie beim Einstellen des Jobs mittels Kommandozeilenparameter), sie sind in der Dokumentation vonsbatch im Abschnitt über Inputvariablen beschrieben. Andere Variablen werden von SLURM beim Einstellen des Jobs gesetzt. Diese können Sie innerhalb des Jobs verwenden, um Job-Einstellungen abzufragen. Hier sind nur ein paar Beispiele gelistet, der Abschnitt über Output-Variablen in der sbatch-Dokumentation enthält eine vollständige Liste.

Variable Funktion
SLURM_CPUS_PER_TASK CPUs per Task.
SLURM_JOB_ID ID-Nummer des Jobs.
SLURM_JOB_NAME Name des Jobs, bei sbatch standardmäßig der Name des Job-Skripts
SLURM_JOB_NUM_NODES Anzahl der Knoten, die zugewiesen wurden.
SLURM_JOB_PARTITION Partition, in welcher der Job läuft.
SLURM_NTASKS Anzahl Tasks
SLURM_TASK_PID Linux-Prozess-ID des entsprechenden Tasks.

Aktualisiert um 16:34 am 8. Februar 2021 von Gerd Pokorra