IT-Service der Fakultät für Physik
print

Sprachumschaltung

Navigationspfad


Inhaltsbereich

Rechencluster LS Parodi

Sichere Benutzung der Rechencluster

Wichtiger Hinweis: Clusterjobs schicken normalerweise Status-Mails (Job gestartet, Job beendet, Job abgebrochen usw). Nachdem die Cluster tausende Rechenkerne zur Verfügung stellen, kann man problemlos mehrere tausend Mails produzieren!! Falls Sie eine Mail-Weiterleitung nach extern eingerichtet haben, gefährdet dies ernsthaft das Mailsystem der Fakultät. Im schlimmsten Fall (wie schon passiert) können 2000 Mailaccounts - einschließlicher derer von Professoren, Dekanen und Vize-Präsidenten - deswegen keine Emails mehr verschicken.

Falls Ihre Statusmails unseren Mailservern Probleme bereiten, wird Ihr Account umgehend deaktiviert.

CLUSTERMAILS NICHT WEITERLEITEN!

Falls Sie eine Weiterleitung nutzen, richten Sie unbedingt einen Filter ein!
(Horde: webmail.physik.uni-muenchen.de -> webmail -> Filter)

 

Information:

Generelle Informationen entnehmen sie bitte den allgemeinen Informationen zur Clusternutzung.

 

Benutzung des Queueing-Systems

Der Rechencluster des LS Parodi ist nur Mitgliedern des Lehrstuhls zugänglich. Daher sind die nachfolgenden Informationen nur für diesen Lehrstuhl von Interesse.

Generelle Informationen entnehmen sie bitte den allgemeinen Informationen zur Clusternutzung.

Empfohlenes Vorgehen

In all Ihren Vorbereitungen und dem Cluster-Batchscript verwenden Sie am besten die Cluster-Home-Umgebungsvariable $MED_CLHOME, denn dann greifen Sie sicher auf das richtige Verzeichnis zu!

Grundlegendes zu Fluka: fluka.sh

#!/bin/bash
#SBATCH --job-name='Fluka SLURM'
#SBATCH --workdir=/home/m/Max.Mustermann/slurm-intro/fluka-batch
#SBATCH --mail-type=ALL
#SBATCH --partition=medcl
#SBATCH --export=NONE
#SBATCH --nodes=1-1
#SBATCH --mem=2048
#SBATCH --time=00:45:00

# load module system
source /etc/profile.d/modules.sh

# load Fluka
module load fluka/2011.2.17-gfortran

RUNDIR=$PWD/E1
CODEDIR=$PWD/code 

cd $CODEDIR
ldpm3qmd MGDRAW_example.f sourcebeam_new.f -o FLUKA_exec

echo --- now running FLUKA ---
cd $RUNDIR
rfluka -e $CODEDIR/FLUKA_exec -N0 -M1 C_E1_example.inp

Wichtig ist in diesem Script die Bereitstellung der Umgebung:

  1. Das Modul-System muss explizit auf dem Cluster verfügbar gemacht werden (das passiert auf den Workstations automatisch)
  2. Dann kann das gewünschte Modul - in diesem Fall eine bestimmte Fluka-Version - geladen werden
  3. Der Rest des Scripts kompiliert lediglich eine Fluka-Simulation und führt sie aus

Noch einmal: Gehen Sie sicher, dass $RUNDIR und $CODEDIR gesetzt sind und die Eingabe- und Ausgabedateien im $MED_CLHOME Dateisystem zur Verfügung stehen!

Zusätzlich zu den oben benutzten Parametern gebrauchen wir

  • --job-name='Fluka SLURM'
    Setze einen Namen für den Job, der von squeue (und anderen) Kommandos angezeigt wird
  • --partition=medcl
    Benutze die medcl Partition, was auch Standard ist (siehe '*' in sinfo)
  • --export=NONE
    Übernehme keine Umgebungseinstellungen vom sendenden System - es ist besser eine saubere Umgebung im Script zu laden.

  • --nodes=1-1
    Benutze "min-max" Knoten zur Verteilung
  • --mem=2048
    Die benötigte Speichergröße in MByte, die der Job zur Laufzeit nutzen sollte (Jobs, die dieser Einschränkung nicht folgen werden aber auch nicht gelöscht). Dieser Wert dient dem Queueing-System lediglich der Einschätzung welche und wie viele Jobs einem Knoten zugewiesen werden können, bevor seine Speicherkapizität ausgelastet ist. Da es sich hierbei nur um einen Hilfswert handelt gibt es keine Garantie dafür, dass der Job tatsächlich diesen maximalen Speicher zugewiesen bekommt, Überwachungsscripte wären dafür notwendig.
  • --time=00:45:00
    Die Maximale Laufzeit des Jobs. Dieser Wert ist nicht zwingend, aber es ist eine gute Vorgehensweise ihn zutreffend zu setzen. Die Angabe wird vom Backfilling benötigt, um die Last auf dem Cluster zu verteilen (Slots, die für große Jobs freigehalten werden können so mit kurzen, kleinen Jobs "aufgefüllt" werden).

Beispiel für die Benutzung mehrerer Kerne: multithread.sh

#!/bin/bash
#SBATCH --job-name='Multithread'
#SBATCH --workdir=/home/m/Max.Mustermann/slurm-intro/multithread
#SBATCH --mail-type=ALL
#SBATCH --partition=medcl
#SBATCH --export=NONE
#SBATCH --nodes=1-1
#SBATCH --ntasks=10
#SBATCH --ntasks-per-core=1
#SBATCH --mem=10240
#SBATCH --time=00:15:00

THREADS=10
TIMEOUT=60

for ((t=0;t<$THREADS;t++))
do
    s
tress --cpu 1 --vm-bytes 1024M --timeout $TIMEOUT &
    sleep 1
done

wait 

Dieses Script führt $THREADS Threads (für $TIMEOUT Sekunden) jeweils auf einer CPU aus und wartet auf ihre Terminierung.

Interessante Parameter von sbatch sind:

  • --ntasks=10
    Definiert, wie viele Threads der Job benutzen wird (in diesem Fall 10). Dies entspricht der Anzahl der Slots, die dem Job zugewiesen werden. In der aktuellen Konfiguration bezeichnet dies 'virtuelle' CPUs (inklusive Hyperthreading-Kerne). Im Endeffekt würde dies dem Job also 5 physische Kerne zuweisen (was 5x2=10 Hyperthreading-Kernen enspricht). Dieses Verhalten wird vom folgenden Parameter überschrieben.
    Bemerkung: Wenn --ntasks kleiner ist als die tatsächliche Anzahl erzeugter Threads, dann werden alle Threads gezwungen auf einer maximalen Anzahl von --ntasks virtuellen CPUs zu laufen. Auf diese Weise kann niemand fremde CPU-Resourcen 'stehlen'.
  • --tasks-per-core=1
    Dieser Parameter legt fest, wie viele Threads auf einem physischen Kern laufen dürfen. In dieser Einstellung (Wert 1) überschreibt es das vorher beschriebene Verhalten des Hyperthreading-Handlings. Es wird ausdrücklich angegeben, dass genau ein Thread pro physischem Kern erlaubt ist, sodass in dieser Kombination beider Parameter 10 physische Kerne reserviert werden.

Weitere Hilfe

Für weitere Hilfe wenden Sie sich bitte an helpdesk-garching@physik.uni-muenchen.de.


Servicebereich

Aktuelle Meldungen