Tipps und Tricks

Tipps und Tricks

module load im Job-Script definieren

Um es Ihnen einfach zu machen, übernimmt Slurm beim Submittieren standardmäßig die Umgebung (environment) und die geladenen Module aus der (Login-) Sitzung, aus der Sie den Job abschicken.

Für die Reproduzierbarkeit einer Job-Umgebung ist es jedoch sinnvoll, ein Jobscript mit module purge zu beginnen und dann alle für den Job notwendigen Module explizit mit module load zu laden. Nur so ist sichergestellt, dass beim Programmlauf wirklich nur die gewünschten bzw. notwendigen Module (in ihrer richtigen Version) verwendet werden.

Das gilt insbesondere, wenn man beispielsweise mit module initadd bestimmte Module automatisch in der eigenen ~/.bashrc lädt, weil man sie wieder und wieder in jeder (Login-) Sitzung benötigt.

Archive entpacken im /work/scratch – Achtung automatische Löschung

Das Entpacken von Archiven (z.B. *.zip, *.tar etc.) verursacht oft das Beibehalten der darin enthaltenden „modification time“ aller Dateien. Sind die entpackten Dateien älter als 8 Wochen, können sie durch die automatischen Lösch-Regeln des Scratch-Bereiches bereits einen Tag später verloren gehen.

Es gibt für die verschiedenen Archive-Programme oft eine Option, um die „modification time“ nicht zu übernehmen, sondern für alle entpackten Dateien einen neuen Zeitstempel zu generieren. Für tar hilft beispielsweise die Option -m. Alternativ kann man für alle gerade entpackten Dateien mit dem Kommando „touch“ nachträglich einen neuen Zeitstempel generieren.

Hinweis: Ab dem 18.4.2017 wird die automatische Löschregel für den Scratch-Bereich auf die „creation time“ umgestellt! Die Aktualisierung der „modification time“ ist danach nicht mehr nötig bzw. hat danach keine Wirkung mehr zur Verlängerung der Speicherzeit von Dateien. Mit der Umstellung auf „creation time“ wird zukünftig das tatsächliche Anlegen einer Datei als Maß für das Alter verwendet – und nach einem Datei-Alter von mehr als 8 Wochen automatisch gelöscht.

Fehlender Slurm-Support in der MPI-Anwendung

Viele Anwendungen haben Probleme die richtige Anzahl Rechenkerne im Batchsystem zu nutzen. Das kann beispielsweise an mangelnder Slurm-Unterstützung liegen. Die meisten dieser problematischen Anwendungen bringen ihre eigene MPI-Version mit und müssen daher explizit mit der richtigen Anzahl Rechenkerne und auch dem so genannten Hostfile unterstützt werden.

Als erstes muss dazu ein aktuelles Hostfile generiert werden. Die nachfolgenden Zeilen ersetzen den sonst üblichen Aufruf „mpirun <MPI-Programm>“:

srun hostname > hostfile.$SLURM_JOB_ID
mpirun  -n 64  -hostfile hostfile.$SLURM_JOB_ID  <MPI-Programm>

Die erste Zeile (oben) erzeugt das Hostfile, die zweite Zeile übergibt dem MPI zusätzlich die Anzahl der zu verwendenden Rechenkerne (hier 64) und den Namen des Hostfiles.

Migration von LSF zu Slurm

Eine Hilfe zur Migration der wichtigsten LSF-Befehle und -Parameter in ihre Slurm-Äquivalente finden Sie hier.

Wichtig: Die Auswahl der richtigen Partition (Queue unter LSF) findet unter Slurm weitestgehend automatisch statt (z.B. bei Verwendung von sbatch oder salloc). Ausgenommen davon sind Spezialfälle wie „kurs*“- oder „extension*“-Queues unter LSF – unter Slurm sind das spezielle Partitionen, Reservierungen oder Projekt-Accounts, die Ihre Jobscripts explizit anfordern müssen.

Einrichten der passwortfreien ssh-Kommunikation zwischen Rechenknoten

Parallele Rechnungen über verschiedenen Knoten hinweg, müssen ohne Abfrage des Passwortes miteinander kommunizieren können. Standardmäßig ist das nicht erlaubt. Man kann das aber im eigenen home-Verzeichnis einstellen:

Geben Sie dazu auf dem lcluster1 (oder lcluster2 bis lcluster12) folgende Befehle ein:

Schlüssel generieren: Die Vorgabe des Speicherortes einfach mit <ENTER> übernehmen.

ssh-keygen -P "" -t rsa -C "$LOGNAME@lcluster"

Den erzeugten Schlüssel für den Login eintragen: Sie werden nach Ihrem Login-Passwort gefragt
(bitte eingeben). Die Konfiguration ist damit beendet.

ssh-copy-id -i .ssh/id_rsa.pub localhost

Zur Überprüfung der Konfiguration: Es sollte jetzt möglich sein, sich ohne Passwort auf einen anderen Login-Knoten (z.B. lcluster4) einzuloggen.

ssh lcluster4

Damit ist die Einrichtung abgeschlossen.

Abschließende Job Details

Mit dem nachfolgenden Kommando kann man sich nach Beendigung eines Jobs mit der <JobID> noch Details über die Ressourcen-Ausnutzung (CPU, Memory etc.) ausgeben lassen.

seff <JobID>

Eine ausführlichere Alternative mit noch mehr Details erhält man auch mit dem nachfolgenden Kommando.

sacct -l -j <JobID>
tuda-seff <JobID>

Gültigkeitsdauer des eigenen Accounts

Das Ablaufdatum des eigenen Benutzeraccounts kann mit dem Script /shared/bin/account_expire abgefragt werden.

Die Laufzeit Ihres Benutzeraccounts ist unabhängig von der Laufzeit bzw. Gültigkeit aller Projekte, denen Sie zugeordnet sind.