Um die Grafikkarten für Deep Learnung-Anwendungen optimal nutzen zu können, ist auf den GPU-Servern am Lehrstuhl der Workloadmanager Slurm installiert.

Überblick

Wir besitzen derzeit mehrere Server mit verschiedenen Grafikkartenmodellen, auf denen gerechnet werden kann. Diese sind in einem Slurm-Cluster verbunden. Um Jobs auf diesem Cluster laufen zu lassen, loggt man sich auf slurmmaster-ls6 per SSH ein. Dort sind die Homeverzeichnisse sowie /scratch verfügbar, jedoch hat der Server selbst weder GPUs noch größere CPU-Leistung. Er dient nur dem Starten von Slurm-Jobs, die dann auf die einzelnen GPU-Server verteilt werden.

Kommunikation und Ressourcenmanagement

Am Lehrstuhl verwenden wir Rocketchat als Kommunikationstool. Alle Nutzer des Clusters sollten dem Kanal ls-6-slurm beitreten. Auf diese Weise können alle sehen, wer viele Ressourcen nutzt, und es ist möglich, sich bei Bedarf direkt an diese Person zu wenden. Dies hilft, die Ressourcennutzung transparent zu gestalten und Engpässe zu vermeiden.

Beitreten des Rocketchat Channels

  1. Öffnen Sie den Rocketchat der Fakultät für Mathematik und Informatik und melden Sie sich mit ihrem Ifi-Account an.
  2. Suchen Sie nach dem Kanal ls-6-slurm.
  3. Treten Sie dem Kanal bei oder bitten Sie ihren Betreuer Sie dem Kanal hinzuzufügen.

Melden von Jobs mit hoher GPU-Auslastung

Da unsere Ressourcen begrenzt sind, ist es wichtig, die Nutzung großer GPUs (GPU1a oder GPU1b) sorgfältig zu planen. Wenn Ihr Job mehr als 8 Stunden GPU-Zeit auf einer dieser großen GPUs benötigt, informieren Sie bitte Ihren Betreuer im Voraus. Dies stellt sicher, dass die Nutzung der GPUs effizient und fair bleibt und potenzielle Engpässe vermieden werden können.

Starten von Jobs

Grundsätzlich wird ein Job in slurm mit den Befehlen srun oder sbatch gestartet. srun gibt die Ausgabe des Jobs auf der Konsole wieder und erlaubt auch interaktiven Zugriff, sbatch leitet den Output in in eine Datei um und erlaubt zusätzlich, Parameter direkt im ausgeführten Script über #SBATCH-Kommentare hinzuzufügen. Empfehlung: sbatch verwenden, wenn kein interaktiver Zugriff notwendig ist. Auf diese Art bleiben Jobs auch erhalten, wenn Server neu gestartet werden müssen.

Ein üblicher Aufruf zum Starten eines Jobs mit einer GPU schaut folgendermaßen aus (Erklärung siehe unten):

sbatch -p ls6 --gres=gpu:1

Im folgenden eine Erläuterung zu einigen Parametern, soweit nicht anders angegeben sind diese für srun und sbatch identisch.

-p: Partition

-p gibt die Partition an, auf der der Job laufen sollen.

Die Partition eines Jobs legt fest, auf welchen Compute Nodes und mit welcher Priorisierung er läuft. Derzeit haben wir nur zwei Partitionen, die auf den selben Nodes laufen und sich nur in der Priorität unterscheiden:

Partition Priorität Nodes
ls6 hoch alle
paramsearch niedrig alle

Für Parametersuchen, bei denen jede Konfiguration als eigener Job gestartet wird, sollte die Partition paramsearch verwendet werden.

--gres: Ressourcen (GPUs nutzen)

Mit dem Parameter –gres wird angegeben, welche Ressourcen der zu planende Job benötigt. Momentan sind das die Grafikkarten. Slurm stellt sicher, dass auf jedem Compute Node dann Jobs entsprechend der verfügbaren Grafikkarten laufen.

--gres=gpu:[typ:]anzahl bedeutet folgendes:

Parameter Bedeutung Mögliche Werte
typ (optional) Welcher Grafikkartentyp wird benötigt? gtx1080ti, rtx2080ti, …
anzahl Wie viele Grafikkarten werden benötigt? Integer. Normalerweise 1

Die verfügbaren GPU-Typen und -Anzahlen pro Node können folgendermaßen ausgegeben werden:

sinfo -o '%12N %G'

Relevante Features bestimmter Grafikkartenmodelle:

Modell Feature
Karten mit rtx besitzen Tensor Cores
rtx3090 größter Speicher mit 24GiB RAM

Will man also einen Job ausführen, der große GPU-Speichermengen benötigt (z.B. Coreferenz-Training) gibt man also --gres=gpu:rtx3090:1 an.

Weitere Parameter

--mem gibt den benötigten RAM an, --cpus-per-task die benötigten CPUs. Alternativ kann mittels --cpus-per-gpu die Anzahl CPUs in Abhängigkeit von den reservierten GPUs angegeben werden.

Mit -J kann dem Job ein alternativer Name gegeben werden (Default: Name des übergebenen Scripts). Nützlich z.B. wenn man mehrere Jobs mit verschiedenen Parametern startet, um die Konfigurationen in den Namen zu schreiben.

Soll aus irgendeinem Grund der Job nur auf bestimmten Nodes laufen, kann man diese mit --nodelist=node1,node2,... festlegen. Umgekehrt können mit --exclude=node1,node2,... bestimmte Nodes ausgeschlossen werden (z.B. wenn bestimmte Grafikkarten nicht kompatibel sind). Welche Nodes existieren, kann über sinfo abgerufen werden.

Jobübersicht

Um eine Übersicht über alle laufenden Jobs zu erhalten, kann das Programm squeue ausgeführt werden. Eine Ausgabe kann dann zum Beispiel so aussehen:

herrmann@slurmmaster-ls6:~$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
              4227       ls6     bash  schmidt  R   19:58:33      1 gpu1a
              4205       ls6     bash studnfis  R 5-16:22:33      1 gpu8a
              3958       ls6     bash studnfis  R 6-22:55:07      1 gpu8a
              3925       ls6     bash studnfis  R 9-16:56:41      1 gpu8a

Job abbrechen

Um einen Job abzubrechen, kann das Programm scancel genutzt werden. Wenn die Job ID (siehe “Jobübersicht”) ermittelt wurde, kann man scancel [jobid] ausführen. Slurm versucht dann zunächsten diesen Job zum Aufhören zu bewegen und, falls das nicht passiert, killt den Job nach einer kurzen Wartezeit.

Interaktive Jobs

Wenn ihr einen interaktiven Job wie eine Shell mit GPU ausführen wollt (z.B. zum Debuggen), könnt ihr dies mittels srun tun, indem ihr den Parameter --pty hinzufügt, z.B.:

srun -p ls6 --gres=gpu:1 --pty bash

CUDA / CuDNN

Auf den Nodes sind verschiedene Versionen von CUDA und CuDNN verfügbar. Die aktuell installierten Kombinationen können mit dem Befehl list-cuda-versions auf dem Master Node aufgelistet werden

Um sicherzugehen, dass die richtige Version genutzt wird, muss LD_LIBRARY_PATH auf den entsprechenden Library-Ordner gesetzt werden (siehe Ausgabe von list-cuda-versions). Dies kann entweder im ausgeführten Script geschehen, oder in der Shell, von der aus der Job gestartet wird (sbatch/srun behalten das Environment bei). Z.B. für CUDA 10.1:

export LD_LIBRARY_PATH="/usr/local/cuda-10.1/lib64:$LD_LIBRARY_PATH"
sbatch -p ls6 --gres=gpu:1 my_job.sh

(Diese Pfade existeren nur auf den Compute-Nodes, welche eine GPU haben.)

Solltet ihr eine CUDA/CuDNN-Kombination benötigen, die nicht installiert ist, wendet euch an die Lehrstuhl-Admins.