From ebecf7740488147ab5f675b0218e0a6a232e1f30 Mon Sep 17 00:00:00 2001 From: Thomas Keller Date: Tue, 20 Aug 2024 14:10:54 +0200 Subject: [PATCH] Update Workstations-Getting-Started.md --- Workstations-Getting-Started.md | 48 ++++++++++++++++++--------------- 1 file changed, 26 insertions(+), 22 deletions(-) diff --git a/Workstations-Getting-Started.md b/Workstations-Getting-Started.md index b31e24c..79de090 100644 --- a/Workstations-Getting-Started.md +++ b/Workstations-Getting-Started.md @@ -14,7 +14,7 @@ Alle Workstations für das Studium sind nach dem folgenden Muster aufgebaut: |Was|Beschreibung| |---|---| -|Login auf den Workstations|Für das Login mit SSH verwendest Du deinen FH Graubünden Benutzername und Passwort| +|Login auf den Workstations|Für das Login mit SSH verwendest Du deinen FH Graubünden Benutzernamen und Passwort| |Homeverzeichnis und Quota|Dein Homeverzeichnis ist auf 80 GB Speicherplatz beschränkt. Welche Möglichkeiten Du hast falls dein Homeverzeichnis voll belegt ist, siehst Du hier ![Troubleshooting](https://gitea.fhgr.ch/CDS/infrastruktur-dok/src/branch/main/Installation-Tensorflow.md#troubleshooting)| |Speicherplatz unter ```/scratch```|Für temporäre Dateien die die Quota von 80 GB überschreiten, kann unter /scratch Speicherplatz verwendet werden. In diesem Verzeichnis bitte **keine vertrauliche Daten** ablegen | |Slurm für den Zugriff auf die GPUs|Die GPUs können nur mit Slurm verwendet werden. Wie das funktioniert steht im Abschnitt [Job Scheduler und Partitionen](#job-scheduler-und-partitionen)| @@ -24,26 +24,26 @@ Alle Workstations für das Studium sind nach dem folgenden Muster aufgebaut: ## Job Scheduler und Partitionen -Da alle Workstation an der FH auch ein Mehrbenutzersysteme sind, können dessen Resourcen nicht jederzeit frei verwendete werden. Daher kommt ein Jobscheduler zum Einsatz, der Rechenjobs mit den zur Verfügung stehenden Ressourcen möchglichst optimal zur Ausführung bringt. Daher musst Du bei einer GPU Berechnung zwingend ![Slurm](https://slurm.schedmd.com/quickstart.html) verwenden. +Da alle Workstation an der FH Mehrbenutzer Systeme sind, können dessen Resourcen (wie die GPUs) nicht jederzeit frei verwendete werden. Daher kommt ein Jobscheduler zum Einsatz, der Rechenjobs mit den zur Verfügung stehenden Ressourcen möchglichst optimal zur Ausführung bringt. Daher musst Du bei einer GPU Berechnung zwingend ![Slurm](https://slurm.schedmd.com/quickstart.html) verwenden. -Grundsätzlich folgt Slurm auf den Workstations dem [FIFO mit Backfill][7] Prinzip. Vereinfacht gesagt bedeutet das, dass der erste eingereichte Job zuerst abgearbeitet wird. Weiter wird die Ressourcennutzung durch sogenannte Partitionen eingeschränkt. Diese bestimmen wie lange ein Benutzer einen Slurm-Job ausführen darf. Die möglichen Partitionen kannst Du mit dem Befehl ```sinfo``` anzeigen lassen. Typischerweise gibt es für die Studierenden die foglenden zwei Partition +Grundsätzlich folgt Slurm auf den Workstations dem [FIFO mit Backfill][7] Prinzip. Vereinfacht gesagt bedeutet das, dass der erste eingereichte Job zuerst abgearbeitet wird. Weiter wird die Ressourcennutzung durch sogenannte Partitionen eingeschränkt. Diese bestimmen wie lange ein Benutzer einen Slurm-Job ausführen darf. Die möglichen Partitionen kannst Du dir mit dem Befehl ```sinfo``` anzeigen lassen. Typischerweise gibt es für die Studierenden die foglenden zwei Partition |Partition | Zweck | Maximale Dauer| |-------|--------------|----| | Debug | Zum Testen und Experimentieren| 5 Min| | Students| Für lange laufende Berechnungen| 7 Tage| -Falls deine Berechnung weniger als sieben Tage benögtigt, sind dir deine Mitstudierenden sicherlich sehr dankbar, wenn Du den Slurmjob beendest sobald deine Berechnung abgeschlossen ist. +Falls deine Berechnung weniger als sieben Tage benögtigt, sind dir deine Mitstudierenden sicherlich sehr dankbar, wenn Du den Slurmjob beendest sobald deine Berechnung abgeschlossen ist. Ansonsten bleibt die GPU für 7 Tage blockiert. -Eine Berechnung die länger als die durch die Partition vorgegebene Zeit läuft wird **abgebrochen**. Diese Limite ist dazu da, damit ein Benutzer nicht irrtümlich oder absichtlich den Cluster für eine unbegrenzte Zeit blockieren kann. Daher empfiehlt es sich dringend, im Skript sogenannte 'Checkpoints' zu implementieren. Wie Checkpoints im Falle von Tensorflow oder Keras implementiert werden, findest Du [hier][11]. Checkpoints schützen übrigens auch vor einem Zeitverlust bei einem Stromausfall. +Eine Berechnung die länger als die durch die Partition vorgegebene Zeit läuft wird **abgebrochen**. Diese Limite ist dazu da, damit ein Benutzer nicht irrtümlich oder absichtlich den Cluster für eine unbegrenzte Zeit blockieren kann. Daher empfiehlt es sich dringend, im Skript sogenannte 'Checkpoints' zu implementieren. Wie Checkpoints im Falle von Tensorflow oder Keras implementiert werden, findest Du [hier][11]. Checkpoints schützen übrigens auch vor einem verlust der Berechnung bei einem Stromausfall oder Diskausfall. -Falls Du deutlich mehr als die oben erwähnten Zeitspannen für eine Berechnung brauchst, melde dich beim DAViS Admin. +Falls Du deutlich mehr als die oben erwähnten Zeitspannen für eine Berechnung brauchst, melde dich bitte beim ![DAViS Admin](mailto:davis-admin@fhgr.ch). -Übrigens: sobald deine Berechnung fertig ist beende auch deinen Slurmjob, zum Beispiel mit ```scancel```. Somit wird die GPU für den nächsten Benutzer freigegeben. +Übrigens: sobald deine Berechnung fertig ist (aber dein Slurmjob noch nicht) beende auch deinen Slurmjob, zum Beispiel mit ```scancel```. Somit wird die GPU für den nächsten Benutzer freigegeben. -## Slurm +## Slurm Commands -Slurm auf den Workstations wird nur zwingend benötigt, wenn deine Berechnung auf der GPU ausgeführt werden soll. Jobs, die nur auf der CPU rechnen, müssen Slurm nicht verwenden. Bei sehr intensiver und lange anhaltender CPU Belegung, empfehlen wir jedoch eine Nutzung von Slurm, damit eine parallel laufende GPU Berechnung nicht gestört wird. +Slurm auf den Workstations wird nur zwingend benötigt, falls deine Berechnung auf der GPU ausgeführt werden soll. Jobs, die nur auf der CPU rechnen, müssen Slurm nicht verwenden. Bei sehr intensiver und lange anhaltender CPU Belegung, empfehlen wir jedoch eine Nutzung von Slurm, damit eine parallel laufende GPU Berechnung nicht gestört wird. Welche Hardware wir auf dem Rechner zur Verfügung haben, können wir uns mit dem Befehl @@ -51,38 +51,42 @@ Welche Hardware wir auf dem Rechner zur Verfügung haben, können wir uns mit de sinfo -o "%N %c %m %G" | column -t ``` -anzeigen lassen. +in Erfahrung bringen. -Mit dem Befehl `srun` kann ein Slurmjob auf dem Cluster ausgeführt werden. Als simples Beispiel berechnen wir hier die Primfaktoren einer grossen Zahl` +Mit dem Befehl `srun` kann ein Slurmjob auf der Workstation ausgeführt werden. Als simples Beispiel berechnen wir hier die Primfaktoren einer grossen Zahl` ``` srun -G a100:1 -p students -n 64 factor 1234567890123456789012345678901234567890 ``` Mit der Option `-p` wird die Partition ausgewählt, im obigen Fall die 'students' Partition. Mit der Option `-n` teilen wir Slurm mit, wieviele parallele Tasks (Prozesse) wir ausführen wollen. Da wir pro Computenode 36 physische Cores und pro Core zwei hyperthreading Cores zur Verfügung haben, können wir den Parameter `-n` auf maximal 64 setzen. Die Option `-G a100:1` fordert eine Nvidia A100 GPU für die Berechnung an. Sobald die Computerresource frei ist, wird der Befehl `srun` ausgeführt und es werden auf der CPU 64 Prozesse gestartet. Sobald die Berechnung abgeschlossen ist, wird das Ergebniss auf der Kommandozeile ausgegeben. -Im obigen Befehl, ist die Option `-G a100:1` nicht nötig und nur als Beispiel aufgeführt. Eine GPU ist für diese Berechnung nicht nötig, da der Befehl `factor` die GPU nicht nutzen kann. +Im obigen Befehl, ist die Option `-G a100:1` nicht nötig und nur als Beispiel aufgeführt, da der Befehl `factor` die GPU nicht nutzen kann. -Für nicht-interaktive und länger laufende Jobs ist es sinnvoll den Befehl `sbatch` zu verwenden. Damit muss nicht gewartet werden bis die Workstation frei wird, sondern der Jobscheduler übernimmt das Skript und bringt es zur Ausführung sobald die Hardwareresourcen frei sind. An welcher Reihe sich mein Job befindet, kann mit dem Befehl +Für nicht-interaktive und länger laufende Jobs ist es sinnvoll den Befehl `sbatch` zu verwenden. Damit muss nicht gewartet werden bis die Workstation frei wird, sondern der Jobscheduler übernimmt das Skript und bringt es zur Ausführung sobald die Hardwareresourcen frei sind. An welcher Reihe sich mein Job in der Jobqueue befindet, kann mit dem Befehl -`squeue` angezeigt werden. +`squeue` angezeigt werden. + +Ein weiterer Vorteil von sbatch ist, dass der Job beim Unterbruch der Netzwerkverbindung nicht abgebrochen wird wie zum Beispiel srun. Für `sbatch` muss ein Shellskript geschrieben werden das einerseits einen Abschnitt enthält mit Informationen für Slurm (diese Befehle sind mit `#SBATCH` gekenntzeichnet) andererseits einen Abschnitt der den Befehl zum Starten der Berechnungen enthält. Dies könnte zum Beispiel so aussehen: ``` #!/bin/bash -#SBATCH --output="slurm-%j.out" ## Logfile. The logfile is written to the current directory -#SBATCH --error="slurm-%j.err" ## Logfile. The logfile is written to the current directory -#SBATCH --time=1:30:00 ## Time limit. Should be equal or smaller than the partitions time limit. In this example the job will be interrupted after 1h and 30 min. -#SBATCH --job-name="Mein Test" ## Job name. This will be used in naming directories for the job. -#SBATCH --partition=students ## Partition to launch job in -#SBATCH --cpus-per-task=1 ## The number of threads the code will use -#SBATCH --ntasks-per-node=64 ## Number of tasks (processes/threads) to run +#SBATCH --output="slurm-%j.out" ## Im Verzeichnis aus dem sbatch aufgerufen wird, wird ein Logfile mit dem Namen slurm-[Jobid].out erstellt. +#SBATCH --error="slurm-%j.err" ## Ähnlich wie --output. Jedoch ein Log für Fehlermeldungen. +#SBATCH --time=1:30:00 ## Zeitlimite. Diese sollte gleich oder kleiner der Partitions Zeitlimite sein. In diesem Fall ist diese auf 1 Stunde und 30 Minuten gesetzt. +#SBATCH --job-name="Mein Test" ## Job Name. +#SBATCH --partition=students ## Partitionsname. Die zur Verfügung stehenden Partitionen können mit dem Befehl sinfo angezeigt werden +#SBATCH --cpus-per-task=1 ## Die Anzahl Threads die Slurm starten soll +#SBATCH --ntasks-per-node=64 ## Die Anzahl Prozesse die gestartet werden sollen # Execute the python script and pass the argument '90' -srun python3 my-mpiProg.py 90 +srun -G a100:1 -p students -n 64 factor 1234567890123456789012345678901234567890 ``` +Ob das Skript nun aktiv ist (oder einfach nur hängt ohne etwas zu machen) ist nicht immer ganz eindeutig festzustellen. Jedoch sieht man mit dem Befehl ```top``` oder ```sudo nvtop``` ob das gestartete Skript CPU oder GPU Resourcen verwendet. Weiter kann in den Logfiles die im sbatch Skript angegeben wurden, nachgeschaut werden ob es Fehler bei der Skriptausführung gegeben hat. Zum Beispiel für den Job 101 mit dem Befehl ```cat slurm-101*```. + Es ist auch möglich eine interaktive Slurm Session zu nutzen. Dazu kann zum Beispiel der folgende Befehl am Workstation Prompt eingegeben werden: ```