Skip to content

SLURM `srun` vs `sbatch` und deren Parameter

Dieser Artikel wurde von Experten getestet, sodass Sie sich auf die Genauigkeit unseres Tutorials verlassen können.

Lösung:

In der Dokumentation steht

srun is used to submit a job for execution in real time

während

sbatch is used to submit a job script for later execution.

Beide akzeptieren praktisch den gleichen Satz von Parametern. Der Hauptunterschied besteht darin, dass srun interaktiv und blockierend ist (Sie erhalten das Ergebnis in Ihrem Terminal und können keine anderen Befehle schreiben, bis es beendet ist), während sbatch eine Stapelverarbeitung ist und nicht blockiert (die Ergebnisse werden in eine Datei geschrieben und Sie können sofort weitere Befehle eingeben).

Wenn Sie srun im Hintergrund mit dem & Zeichen, dann heben Sie die "blockierende" Funktion von srunauf, wodurch es interaktiv, aber nicht blockierend wird. Es ist aber immer noch interaktiv, was bedeutet, dass die Ausgabe Ihr Terminal überladen wird, und das srun Prozesse sind mit Ihrem Terminal verbunden. Wenn Sie die Verbindung unterbrechen, verlieren Sie die Kontrolle über sie, oder sie werden möglicherweise beendet (je nachdem, ob sie stdout verwenden oder nicht). Und sie werden beendet, wenn der Rechner, mit dem Sie sich verbinden, um Aufträge zu übermitteln, neu gestartet wird.

Wenn Sie sbatchverwenden, senden Sie Ihren Job und er wird von Slurm bearbeitet; Sie können die Verbindung trennen, Ihr Terminal beenden usw., ohne dass dies Folgen hat. Ihr Auftrag ist nicht mehr mit einem laufenden Prozess verbunden.

Welche Dinge kann ich mit dem einen Programm tun, die ich mit dem anderen nicht tun kann, und warum?

Eine Funktion, die für sbatch und nicht für srun ist Job Arrays. Als srun innerhalb einer sbatch Skripts verwendet werden kann, gibt es nichts, was man nicht mit sbatch.

In welchem Verhältnis stehen sie zueinander, und wie unterscheiden sie sich bei srun und sbatch?

Alle Parameter --ntasks, --nodes, --cpus-per-task, --ntasks-per-node haben in beiden Befehlen die gleiche Bedeutung. Das gilt für fast alle Parameter, mit der bemerkenswerten Ausnahme von --exclusive.

Was geschieht "unter der Haube", dass dies der Fall ist?

srun führt das Skript sofort auf dem entfernten Host aus, während sbatch das Skript in einen internen Speicher kopiert und es dann auf den Rechenknoten hochlädt, wenn der Auftrag beginnt. Sie können dies überprüfen, indem Sie Ihr Übermittlungsskript nach der Übermittlung änderned; Änderungen werden nicht berücksichtigt (siehe dies).

Wie interagieren sie miteinander, und was ist der "kanonische" Anwendungsfall für jeden von ihnen?

Normalerweise verwendet man sbatch um einen Auftrag zu übermitteln und srun im Übermittlungsskript, um Job-Steps zu erstellen, wie Slurm sie nennt. srun wird verwendet, um die Prozesse zu starten. Wenn Ihr Programm ein paralleles MPI-Programm ist, srun für die Erstellung aller MPI-Prozesse zuständig. Wenn nicht, srun Ihr Programm so oft ausführen, wie es durch den Parameter --ntasks Option angegeben ist. Es gibt viele Anwendungsfälle, je nachdem, ob Ihr Programm parallel läuft oder nicht, ob es eine lange Laufzeit hat oder nicht, ob es aus einer einzigen ausführbaren Datei besteht oder nicht, usw. Wenn nicht anders angegeben, srun standardmäßig die entsprechenden Optionen der Option sbatch oder . salloc unter dem es läuft (von hier aus).

Konkret: Würde ich srun jemals alleine benutzen?

Außer für kleine Tests, nein. Eine übliche Verwendung ist srun --pty bash um eine Shell für einen Rechenjob zu bekommen.

Das beantwortet die Frage zwar nicht ganz, aber hier sind weitere Informationen, die ich gefunden habe und die für jemanden in der Zukunft hilfreich sein könnten:


Aus einem verwandten Thread, den ich mit einer ähnlichen Frage gefunden habe:

Kurz gesagt: sbatch und salloc weisen dem Job Ressourcen zu, während srun parallele Aufgaben über diese Ressourcen startet. Wenn srun innerhalb einer Jobzuweisung aufgerufen wird, startet es parallele Aufgaben über einige oder alle zugewiesenen Ressourcen. In diesem Fall erbt srun standardmäßig die entsprechenden Optionen von sbatch oder salloc, unter denen es läuft. Sie können srun dann (normalerweise) verschiedene Optionen geben, die die Standardoptionen überschreiben. Jeder Aufruf von srun innerhalb eines Jobs wird als Job-Step bezeichnet.

srun kann auch außerhalb einer Jobzuweisung aufgerufen werden. In diesem Fall fordert srun Ressourcen an, und wenn diese Ressourcen gewährt werden, startet es Aufgaben über diese Ressourcen als einen einzelnen Job und Job-Step.

Es gibt eine relativ neue Webseite, die auf die Optionen -B und --exclusive genauer eingeht.

doc/html/cpu_management.shtml


Zusätzliche Informationen auf der SLURM-FAQ-Seite.

Der Befehl srun hat zwei verschiedene Funktionsweisen. Erstens, wenn er nicht innerhalb eines existierenden Jobs ausgeführt wird (d.h. nicht innerhalb einer Slurm-Job-Zuweisung, die durch salloc oder sbatch erstellt wurde), dann wird er eine Job-Zuweisung erstellen und eine Anwendung starten. Wenn der Befehl srun innerhalb einer bestehenden Zuweisung ausgeführt wird, wird nur die Anwendung gestartet. In dieser Frage werden wir uns nur mit der ersten Betriebsart befassen und die Erstellung einer Auftragszuweisung mit den Befehlen sbatch und srun vergleichen.

Der Befehl srun ist für den interaktiven Einsatz konzipiert, bei dem jemand die Ausgabe überwacht. Die Ausgabe der Anwendung ist als Ausgabe des srun-Befehls zu sehen, typischerweise auf dem Terminal des Benutzers. Der sbatch-Befehl dient dazu, ein Skript zur späteren Ausführung zu übermitteln, und seine Ausgabe wird in eine Datei geschrieben. Die bei der Auftragszuweisung verwendeten Befehlsoptionen sind fast identisch. Der auffälligste Unterschied bei den Optionen besteht darin, dass der sbatch-Befehl das Konzept der Job-Arrays unterstützt, während srun dies nicht tut. Ein weiterer wesentlicher Unterschied liegt in der Fehlertoleranz. Fehler bei sbatch-Aufträgen führen in der Regel dazu, dass der Auftrag erneut in die Warteschlange gestellt und ausgeführt wird, während Fehler bei srun in der Regel dazu führen, dass eine Fehlermeldung erzeugt wird, in der Erwartung, dass der Benutzer in angemessener Weise reagiert.


Ein weiteres relevantes Gespräch hier

Wir zeigen Ihnen die Kommentare und Bewertungen der Leser

Wenn Sie zögern oder bereit sind, unseren Abschnitt voranzutreiben, können Sie eine Notiz hinterlassen, die wir gerne interpretieren.



Nutzen Sie unsere Suchmaschine

Suche
Generic filters

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.