Jobs einreichen mit SLURM: Unterschied zwischen den Versionen
Aus HPC@HU
(→Verfügbare Ressourcen:: - Update scratch space) |
|||
Zeile 51: | Zeile 51: | ||
* 64 Threads (ûber 32 Kerne) | * 64 Threads (ûber 32 Kerne) | ||
* 256GB Arbeitsspeicher | * 256GB Arbeitsspeicher | ||
* knapp | * knapp 1,5TB lokaler scratch |
Version vom 2. Juli 2024, 07:38 Uhr
Einführung
Der Queue-Manager für HPC@HU ist SLURM ( siehe https://slurm.schedmd.com/quickstart.html )
Ein Beispiel kann wie folgt aussehen:
#!/bin/bash
#SBATCH --ntasks=1 # Run on a single CPU
#SBATCH --mem=1gb # Job memory request
#SBATCH --time=00:05:00 # Time limit hrs:min:sec
#SBATCH --partition=std
#SBATCH --account=nutzername
hostname
Hier steht hostname beispielhaft für einen Script oder die Ausführung einer Software für Berechnungen.
Sollten im Script Variablen gesetzt werden, ist es wichtig dass dies erst nach der Definition des Jobs für SLURM geschieht.
Nennt sich der Scirpt submit.bash
, lässt sich dieser dann über
sbatch submit.bash
beim Scheduler einreichen.
Der aktuelle Status lässt sich über
squeue
oder
squeue -u Nutzername
abfragen.
Parallelisierung mit mehreren Compute-Knoten:
Es ist möglich Berechnungen über mehrere Compute-Knoten laufen zu lassen. Hierbei sollte bedacht werden, dass Abhängig von den Virtuellen Maschinen in der aktuellen Konfiguration, die Kommunikation lokal auf einem Server oder über 100GBit/s Ethernet stattfindet.
Hierbei ist die Integration von openMPI und SLURM von der Nutzerseite einfach zu handhaben.
Um eine Berechnung über 2 Compute-Knoten laufen zu lassen, definiere ich zum Beispiel meine Anzahl an Threads sowie die Anzahl der Knoten:
#!/bin/bash #SBATCH --ntasks=40 # Run 40 threads/processes #SBATCH --ntasks-per-node=20 # Run 20 per compute node #SBATCH --nodes=2 # Run on 2 nodes #SBATCH --mem=80gb # Job memory needed per node (per node is important!!) #SBATCH --time=96:00:00 # Time limit hrs:min:sec #SBATCH --partition=std #SBATCH --account=<user account>
Danach rufe ich mein Programm ganz gewöhnlich über mpirun auf. Ein Punkt den es zu beachten gibt, ist dass es notwendig ist die zulässigen Ports für die Kommunikation zwischen Nodes zu definieren, vor allem der minimale Port scheint hier wichtig zu sein.
Dadurch sieht der Aufruf des Programms (hier xhpl) dann wie folgt aus:
mpirun -np 40 --mca btl_tcp_port_min_v4 60001 --mca oob_tcp_dynamic_ports 60001-63000 xhpl
Verfügbare Ressourcen:
Aktuell eingerichtete virtuelle Maschinen verfügen über je:
- 64 Threads (ûber 32 Kerne)
- 256GB Arbeitsspeicher
- knapp 1,5TB lokaler scratch