Parameter sbatch

Parameter des Kommandos „sbatch“

Zur besseren Nachvollziehbarkeit empfehlen wir, alle Parameter/Pragmas im Job-Script explizit aufzuführen (anstatt sie sbatch als Kommandozeilenparameter zu übergeben). Beispiele dafür finden Sie auf den Reitern oben mit den entsprechenden Scripten (MPI, OpenMP, MPI+OpenMP).

Hier sind nur die wichtigsten Pragmas des sbatch-Kommandos angeführt. Eine vollständige Parameterliste liefert das Kommando ''man sbatch'' auf den Login-Knoten (z.B. lcluster4).

-A Projekt-Bezeichnung
Für das Accounting kann man hiermit eins der eigenen Projekte auswählen, auf das die verwendeten Core-Stunden gebucht/abgerechnet werden. Die Projektnamen bestehen im Allgemeinen aus dem Wort „project“, gefolgt von einer 5stelligen Zahl, also z.B. „project12345“.
Achtung: Jeder Nutzer hat ein default-Projekt (meist sein erstes angemeldetes). auf das automatisch gebucht wird, wenn man diese Option nicht angibt!

-J Job_Name
Weist dem Job einen frei wählbaren, beschreibenden Namen zu.

--mail-type=BEGIN
Sendet eine E-Mail beim Start des Jobs.
--mail-type=END
Sendet eine E-Mail beim Ende des Jobs.
--mail-type=ALL
Sendet Mails bei beiden Vorgängen (und in einigen weiteren Fällen).

Bitte beachten: wenn man sehr viele Jobs einzeln abschickt, werden dementsprechend sehr viele Mails erzeugt. Das hat in der Vergangenheit dazu geführt, dass diverse eMail- bzw. Internet Service Provider die Mailserver der TU als „spammer“ auf ihre Blacklisten gesetzt haben. Das Mail- und Groupware-Team des HRZ hatte dann sehr viel Mühe, dieses Blacklisting rückgängig zu machen.

Vermeiden Sie dies bitte mittels

  • job arrays (#SBATCH -a 1-100 für 100 gleichartige Jobs)
  • --mail-type=NONE – stattdessen mittels „squeue“ prüfen, welche Jobs noch laufen und welche fertig sind

-o /pfad/zu/AusgabeDatei_Name (besser mit vollständigen Pfad)
Schreibt die Standard-Ausgabe STDOUT des gesamten Jobs-Scripts in die genannte Datei.
-e /pfad/zu/FehlerDatei_Name (besser mit vollständigen Pfad)
Schreibt den Fehler-Kanal STDERR in die genannte Datei.

Bei beiden Optionen empfehlen wir, den vollen Pfadnamen anzugeben, um versehentliches Überschreiben anderer Job-Ausgaben und -Fehlerdateien zu vermeiden.

-n Task_Zahl
Gibt die Anzahl an Tasks für diesen Job an. Sofern nicht anders spezifiziert, stimmt dies mit der Anzahl der benötigten Rechenkerne überein, auf denen der Job laufen soll.

-c Kerne_pro_Proz_Zahl
Gibt die Anzahl der Rechenkerne pro Task an. Für OpenMP sollte man -n auf 1 setzen und -c auf die Anzahl der OpenMP-Threads. Voreinstellung: 1

--mem-per-cpu=Speicher
Definiert den maximalen Hauptspeicher-Bedarf pro angefordertem Rechenkern in MByte.

-t Laufzeit
Setzt das Laufzeit-Limit für den Job. Ein Job, der sich innerhalb dieser Zeit nicht selbst beendet, wird vom Batchsystem automatisch abgebrochen.
Die Zeit kann als einfache Zahl in Minuten oder auch in Form 00:00:00 (Stunden:Minuten:Sekunden) spezifiziert werden.

-C feature
Fordert spezielle Features (Eigenschaften) für die Rechnknoten an, z.B. AVX2 oder NVIDIA-GPUs. Features dürfen mittels „&“ verknüpft werden. Erlaubte Features sind u.a.:

  • sse, avx, avx2
  • nvd, nvd2, nvd4, nvd8
  • phi, phi5, phi7 (diese Features sind seit August 2018 deaktiviert)
  • (multi): Nur für spezielle Fälle

-d Dependency
Hiermit lassen sich Abhängigkeiten zwischen verschiedenen Jobs definieren. Details liefert das Kommando ''man sbatch''.

Tipps und Tricks

--exclusive
Fordert die Rechen-Knoten job-exklusiv an. Diese Option kann wichtig sein, wenn man weniger Rechenkerne pro Knoten anfordert als vorhanden sind (16 bei Phase-I- und 24 bei Phase-II-Knoten). In so einem Fall könnte Slurm weitere Jobs (desselben Nutzers) auf denselben Knoten schicken. Da das das Laufzeitverhalten des ersten Jobs beeinflussen (und so möglicherweise Zeit- oder Performancemessungen verfälschen) könnte, stellt diese Option sicher, dass der damit gestartete Job allein auf dem Knoten ist.

Jobs anderer Benutzer dürfen sowieso nicht auf einen bereits benutzten Knoten – unsere Konfiguration ist per se user-exklusiv.