FAQ - Häufig gestellte Fragen und ihre Antworten

Die Nutzung des Clustersystems ist kostenlos für Mitarbeiter der LUH und für Projekte, die mit öffentlichen Geldern gefördert sind.

Nein.  Unter bestimmten Umständen (die Anforderung ist mehr als zweimal so groß wie der tatsächliche Verbrauch) erhält man eine Email mit dem Hinweis, die Job-Anforderungen besser anzupassen. Diese Email dient nur zur Information und zieht keine weiteren Konsequenzen nach sich. Ein Nachteil ergibt sich aber aus der großen Anforderung: In der Regel wird der Job länger in der Queue warten müssen.

Man lässt kleine Tests auf Avon, Orac oder in der Test-Queue laufen, und misst wie lange diese Jobs dauern.  Mit dem Wissen,  wie groß der eingentliche Job sein wird und wie groß die Test-Jobs waren, kann man ungefähr ausrechnen, wie lange ein Job dauern wird.  Dann fügt man etwas Puffer dazu, falls der Job doch länger läuft (man möchte nicht zu wenig Zeit anfordern!).

Ganz ähnlich wir bei der Abschätzung der Zeit kann man die Arbeitsspeicherauslastung am lokalen PC extrapolieren und dann noch etwas Puffer dazugeben.

Nach Beendigung des Jobs kommt dann ohnehin immer eine Email vom System, die die
Information enthält, wie viel Hauptspeicher Sie tatsächlich genutzt
haben (sie enthält auch die verbauchte Wallclock-Zeit). Daraus kann man lernen und die Jobanforderung anpassen, wenn man zu viel gewählt hatte.

Verwendet man mehr  als angefordert wurde, wird der Job (leider) vom System abgebrochen.

Auch das kann man als Feedback nutzen und seine Anforderung entsprechend beim nächsten Mal höher wählen. Nach kurzer Zeit bekommt ein Gefühl für die nötigen Anforderungen.

Helena ist ein Rechner, der ein besonderes Hauptspeicher-Layout hat.  Der Rechner sieht zwar aus als ob er aus 160 CPUs und 640 GB Hauptspeicher besteht, aber in Wirklichkeit ist er aus 10 Server-Blades aufgebaut, die jeweils 16 Kerne und 64 GB Hauptspeicher besitzen.  Diese Blades sind mit einem besonderen Netzwerk verbunden (Numalink) damit der Rechner ein Systemimage bildet. Speicherverwaltung und Prozessorverwaltung können das Programm verlangsamen. auf beide wollen wir kurz eingehen:

Speicherverwaltung

Die Numalink-Konfiguration hat zur Folge, dass man ein Programm auf einem Blade laufen lassen kann, dabei aber möglicherweise Hauptspeicher auf einem anderen Blade benutzt wird.  Diese Situation ist nicht besonderes leistungsfähig im Vergleich zu Speicherzugriffen direkt am selben Blade, aber für Programme mit besonders großen Hauptspeicheranforderungen ist es unter Umständen die einzige Möglichkeit, überhaupt laufen zu können.

Prozessorverwaltung

Auch durch die große Anzahl an verfügbaren Rechenkernen kann man Geschwindigkeitsprobleme bekommen.  Dies passiert bei Programmen, die automatisch Parallelismus anschalten.  Vor allem Matlab Programme sind betroffen, aber auch Fortran- oder C-Codes, die mit dem Intel-Compiler mit der '-parallel' Option übersetzt worden sind.

Hierbei entsteht durch die Kommunikation der (parallelen) Prozesse untereinander ein Overhead, der umso größer wird, je mehr Prozesse beteiligt sind. Probleme parallel zu berechnen ist also sinnvoll, nur darf die Anzahl der parallelen Instanzen nicht zu groß werden. Die optimale Anzahl an parallelen Prozessen für ein Problem sollte man also immer vorher durch eine Studie ermitteln. Die Zahl der Prozessoren immer weiter zu erhöhen führt irgendwann zu einer Leistungseinbuße durch Kommunikationsoverhead, eine Gefahr, die gerade bei Helena existiert (160 Kerne!).

Manchmal kommt es vor, dass man viele Jobs in die Queue abgesetzt hat aber nachhinein feststellt, dass ein Fehler im Batchskript oder im Job selbst steht.  Man möchte natürlich diese Jobs abbrechen und neuen Jobs in die Queue absetzen.  Aber wie kann man schnell und leicht alle diese Jobs löschen?  Man kann eine der folgenden Prozeduren verwenden:

Alle Jobs löschen

Zuerst baut man eine Liste alle seine Jobs auf:

jobs=$(qselect -u <benutzername>)

Dann baut man eine Schleife, die alle Jobs hintereinander löscht:

for job in $jobs
do
    qdel $job
done

Nur wartende Jobs löschen

Zuerste eine Liste alle wartenden ("idle") Jobs erstellen:

jobs=$(qselect -s Q -u <benutzername>)

Dann verwendet man eine Schleife, damit die Jobs gelöscht werden:

for job in $jobs
do
    qdel $job
done

Damit man Simulationsdaten dauerhaft speichern kann gibt es das Archivsystem.  Alle Clusternutzer können Zugriff zum Archivsystem bekommen, aber per default ist dies nicht freigeschaltet.  Um den Zugriff für Ihren Account freizugeben, navigiert man zum BIAS-Administrationssystem (https://bias.rrzn.uni-hannover.de) und loggt sich mit den normalen Clusterzugriffsdaten ein.  Dann kann man auf einen Link namens "Ihren Benutzernamen für die Nutzung des Archivsystems zulassen" klicken.  Dies schaltet den Account für Archivzugriff frei, allerdings nicht instantan, sondern etwa nach einer Stunde. Jetzt kann man Daten ins Archiv kopieren.

Von einem Loginknoten aus, wechselt man in das Verzeichnis wo seine Daten liegen:

login_node:~$ cd $BIGWORK/my_data_dir

Login zum Archivserver

Dann loggt man sich auf den Archivserver (uqfs.rrzn.uni-hannover.de) mit dem 'lftp'-Kommando ein:

login_node:~$ lftp <username>@uqfs.rrzn.uni-hannover.de

Man wird nach dem normalen Cluster-Passwort gefragt.  Nach Eingabe des Passworts bekommt man den 'lftp'-Prompt:

lftp <username>@uqfs.rrzn.uni-hannover.de:~>

Jetzt kann man einfach den Befehl 'ls' eingeben um zu sehen ob eine Verbindung erfolgreich aufgebaut werden kann:

lftp <username>@uqfs.rrzn.uni-hannover.de:~> ls

Man sollte kurzzeitig eine Meldung wegen [Logging in...] sehen und vielleicht etwas über [FEAT Negotiation]. Wenn alles gut läuft, sieht man eine Liste der Dateien, die bereits im Archivverzeichnis liegen. Falls das nicht funktioniert (und das Passwort korrekt ist) sollte man Kontakt mit dem Clusterteam aufnehmen (über cluster-helprrzn.uni-hannover.de) um
das weiterhin zu erforschen.

Kopieren von einem Loginknoten ins Archivsystem

Um Dateien ins Archivsystem zu kopieren benutzt man den 'put' Befehl (von innerhalb 'lftp'):

lftp <username>@uqfs.rrzn.uni-hannover.de:~> put myfile.tar.gz

(Tab-Vervollständigung funktioniert übrigens)

Um mehrere Dateien auf einmail zu kopieren (alle sollen große .tar.gz-Dateien sein) benutzt man den 'mput' Befehl (multiple put):

lftp <username>@uqfs.rrzn.uni-hannover.de:~> mput mydata*.tar.gz

Kopieren vom Archivsystem zu einem Loginknoten

Um Dateien vom Archivsystem zurückzuholen benutzt man wiederum den 'get' (bzw. 'mget') Befehl:

lftp <username>@uqfs.rrzn.uni-hannover.de:~> get myfile.tar.gz

Andere Befehle

Um das lokale Verzeichnis zu sehen (also, das Verzeichnis auf einem Loginknoten zum Beispiel), benutzt man '!ls'; ein Ausrufezeichen führt das Kommando auf dem Rechner aus, wo man 'lftp' gestartet hat. Als Beispiel davon, damit man sieht in welchem Verzeichnis man zur Zeit (auf dem Loginknoten) sich befindet, benutzt man '!pwd' am 'lftp'-Prompt.

Man kann auch auf dem Archivsystem Verzeichnisse anlegen; dies erfolgt durch das 'mkdir'-Kommando:

lftp <username>@uqfs.rrzn.uni-hannover.de:~> mkdir mydir

Und Verzeichniswechseln funktioniert wie gehabt mit 'cd':

lftp <username>@uqfs.rrzn.uni-hannover.de:~> cd mydir

oder um eine Ebene höher im Verzeichnisbaum zu wechseln:

lftp <username>@uqfs.rrzn.uni-hannover.de:~> cd ..

Um das lokale Verzeichnis (auf dem Loginknoten) zu wechseln, benutzt man den 'lcd'-Befehl (local cd):

lftp <username>@uqfs.rrzn.uni-hannover.de:~> lcd /bigwork/<username>/datadir

Beendet wird die Verbindung mit "exit":

lftp <username>@uqfs.rrzn.uni-hannover.de:~> exit

<username>@login_node:~$

Es kann passieren, dass das module Kommando auf der Konsole nicht zur Verfügung steht.  Die Fehlermeldung könnte so aussehen:

module: command not found

Dies bedeutet nur, dass ein Initialisierungsskript nicht gelaufen ist, was häufig in grafischen Oberflächen (wie z.B. über NX) der Fall ist.  Um in der aktuellen Shell/Konsole die Modules-Umgebung bereitzustellen muss man nur den folgenden Befehl benutzen (vorausgesetzt, dass die bash-Shell benutzt wird):

$ source /usr/share/Modules/init/bash

oder auch

$ bash -l

Im Allgemeinen kann man dieses Kommando benutzen:

source /usr/share/Modules/init/`basename $SHELL`

Damit die Modules-Umgebung in Batchjobs zur Verfügung steht, sollte die allererste Zeile des Batchskripts diese sein:

#!/bin/bash -login

Anstatt immer wieder den obengenannten source-Befehl einzugeben kann man diesen auch der ~/.bashrc hinzufügen:

echo 'source /usr/share/Modules/init/bash >> ~/.bashrc'

Beim nächsten Login wird die Modules-Umgebung automatisch zur Verfügung stehen.

Möchte ein Client (der Rechenknoten, an dem ein Job gerade läuft) auf eine
Datei (schreibend oder lesend) zugreifen, fragt der Client den Meta-Data
 Server(MDS) und damit auch den Meta-Data Target(MDT) nach dem Layout, der
aktuellen Position und Informationen über die Streifen (Stripes) der Datei. Sobald
die Datei geöffnet wird und der Client Streifen-Infos(Striping-Information)
über die Datei erhält, hört die Beteiligung des MDS am I/O-Prozess auf.  Alle
weiteren I/O-Operationen - unter anderem (Locking[Blockierung],
disk-allocation[Plattenzuteilung], storage[Lagerung] u.s.w... - werden direkt mit
dem OSS(es) und OST(es) abgewickelt.

Der Lustre Server kann nur ungefähr 10.000 bis 20.000 entfernte RPC's
(Remote Procedure Calls , die vom Klienten auf dem Server durchgeführt
werden) pro Sekunde durchführen. Durch einen sehr hohen gleichzeitigen Zugriff auf Ressourcen, wird die Performance von Anwendungen verlangsamt und die gesamte Stabilität des Lustre Datei-Systems geschwächt

Um dies zu vermeiden und somit eine Steigerung der Performance zu erreichen, nutzen Sie bitte für das Clustersystem (so weit es geht) in Ihren Jobs die unten stehenden Tipps:

Vermeiden Sie bitte die Verwendung von "ls -l"!

Der Befehl "ls -l" gibt uns uns Informationen wie Eigentumsrecht (ownership),
Erlaubnis (permission) und Größe (size) aller Dateien und Verzeichnisse zurück.
Solche Informationen werden auf dem MDT (Metadata Server) aufbewahrt.  Jedoch
ist die Metadata-Dateigröße nur vom OST aus verfügbar, sodass der Befehl "ls -l",
RPC's-Aufrufe (Remote Prozedur Call) auf dem MDS/MDT und OSSes/OSTs
verursacht. Da RPC-Anfragen sehr kostspielig sind, kann bei vielen Dateien und
Verzeichnissen viel Zeit beansprucht werden.

Wann soll ich den Befehl "ls" verwenden?

Verwenden Sie "ls" allein, wenn Sie gerade sehen wollen, ob eine Datei vorhanden ist.

Wann soll ich den Befehl "ls -l" verwenden?

Verwenden Sie "ls -l <Dateiname>", wenn Sie die lange Auflistung einer spezifischen Datei sehen wollen.

Wie teile ich am bestens Dateien und Verzeichnisse auf?

• Vermeiden Sie eine Vielzahl von Dateien in einem einzelnen Verzeichnis.

Das Öffnen einer Datei erstellt ein "Lock" (Schloss) auf dem Eltern-Verzeichnis. Wenn viele Dateien im selben Verzeichnis geöffnet werden sollen, gibt es sehr einen sehr hohen gleichzeitigen Zugriff auf Ressourcen (durch RPC's). Es ist besser, eine riesige Anzahl von Dateien in mehrere Unterverzeichnisse aufzuteilen.

•  Verwenden Sie  eine "Stripsize" (Zählung) von 1 für Verzeichnisse mit vielen kleinen Dateien.

z.B.: Für die Erzeugung eines Verzeichnisses namens "verzeichnis_name" mit
"Stripsize=1 (--size 1m), das nur auf einem OST liegt(--count 1) geben Sie
folgendes ein:

  nutzer@login-node /bigwork/nutzer$ mkdir verzeichnis_name
  nutzer@login-node /bigwork/nutzer$ lfs setstripe --size 1m --count 1 erzeichnis_name

  PS: Natürlich gilt das auch für einfache Dateien.

Falls kleine Dateien auf dem Lustre Datei-System behalten werden müssen, sind die
"stat" Operationen (liefern verschiedene Attribute wie Zugriffszeit, Änderungszeit usw..) am effizientesten, wenn diese Dateien auf einen OST (also nicht über mehrere OSTs verteilt) liegen.

Vermeiden Sie den Zugriff von ausführbaren Dateien in /bigwork

Es hat einige Probleme auf /bigwork gegeben, wo Benutzer-Jobs teilweise auf ihre ausführbaren Dateien nicht mehr zugreifen konnten. Dies liegt daran, dass der Lustre-Klient vom System temporär abmontiert werden kann, falls die Last zu hoch sein sollte. Das kann zu Bus-Fehlern führen, wenn der Job z.B. den nächsten Satz von Instruktionen von einer nicht vorhandenen ausführbaren Datei in den Arbeitsspeicher bringen möchte.

Dieses Problem kann viele verschiedene Ursachen haben:

Das Clustersystem ist voll

Es kann sein, dass das Clustersystem bereits voll ist und die Ressourcenanforderungen des Jobs zur Zeit nicht erfüllt werden können.  Um dies zu überprüfen, schaut man auf den Betriebsstatus des Clustersystems um zu sehen wie viele Jobs zur Zeit laufen.  Was gibt qstat -a aus?  Ist da auch viel los?  Was sieht die Ausgabe von showq aus (ein anderer Sicht auf den Status der Queue)?  Wenn der Job im IDLE Abschnitt steht, dann muss man leider warten: Es gibt also zur Zeit keine Ressourcen frei.  Wenn der Job im BLOCKED Abschnitt steht, könnte es sein, dass die maximale Grenzen für diesen User-Account erreicht worden sind.

Die maximale Grenzen der Benutzerkennung sind bereits erreicht

Ein Job kann in der Queue hängen wenn die Nutzerkennung bereits die Obergrenze an Ressourcen belegt hat.  Derzeit ist die Obergrenze an gleichzeitig laufenden Jobs auf 64 gesetzt.  Die maximale Anzahl an belegten Prozessoren ist aber derzeit auf 768 (also 64*12).  Wenn eine diese Grenzen bereits erreicht worden ist, dann kann kein anderer Job der selben Kennung starten bis genügend Ressourcen frei geworden sind.  Dies ist auch dann der Fall, wenn das Clustersystem Platz für den Job hätte: Wir bewahren Ressourcen für andere Nutzer auf, die wohl demnächst diese Rechenressourcen benutzen wollen.

Man kann erkennen, ob man diese Grenze erreicht hat, wenn man ausrechnet, wie viele Ressourcen durch laufende Jobs bereits belegt sind und sich die Frage stellt, ob man mit den neuen Ressourcen-Anforderungen die Grenzen (s.o.) überschreitet.  Wenn ja, dann muss man warten bis Ressourcen wieder freigeworden sind.  Durch den showq Befehl kann man auch erkennen ob man in so einem Fall gelandet ist: Der Job befindet sich im BLOCKED Abschnitt der Ausgabe.

Die Ressourcenanforderungen passen nicht zur Rechnerressourcen

Es kann auch vorkommen, dass die Ressourcenanforderungen gar nicht mit der Hardwareressourcen zusammenpassen.  Dies kommt häufig vor bei Nutzern, die die PARTITION-Anweisung in ihren Jobskripten benutzen.  Zum Beispiel, man fordert 4 Knoten mit jeweils 4 Prozessoren an und mit 400GB Hauptspeicher insgesamt, also

#PBS -l nodes=4:ppn=4
#PBS -l mem=400gb

Diese Jobanforderungen sind vollkommen legitim (der Job wird wohl auf dem SMP-Cluster laufen) aber wenn man jetzt sich auf den Tane-Cluster einschränkt:

#PBS -W x=PARTITION:tane

dann kann der Job nie anlaufen, weil ein einzelner Tane-Knoten nur 47GB verfügbaren Hauptspeicher hat und 4*47GB < 400GB ist.

Der Rat an dieser Stelle: bitte immer überprüfen, ob die angeforderten Ressourcen mit den verfügbaren Hardwareressourcen zusammenpassen.

Eine Wartung ist geplant oder läuft bereits

Das Clustersystem wird ab und zu gewartet.  Manchmal warten wir nur Teile des Gesamtsystems, manchmal das gesamte System.  Wenn eine Wartung ansteht, kann es sein, dass ein Job nicht anläuft, weil durch die von ihm geforderte Wallclock-Zeit das Ende des Jobs innerhalb der geplanten Wartung liegt. Dadurch wird der Job nicht anlaufen.

Wann Wartungen stattfinden, erfährt man über die Liste cluster-newsrrzn.uni-hannover.de , über unser Forum oder in der "Message of the day" beim Aufschalten auf das System.

Die obigen Punkte treffen nicht zu.  Was tun?

Wenn der Job in der Queue hängt, und er ist im BLOCKED-Abschnitt der showq-Ausgabe zu sehen und die obigen Punkte sind nicht gültig, dann ist etwas verkehrt.  Schicken Sie uns bitte eine Mail an cluster-helprrzn.uni-hannover.de.