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. Drei Gründe können das Programm verlangsamen: Speicherverwaltung, Prozessorverwaltung und starker I/O. Wir wollen auf alle drei 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 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.

Ein Beispiel: Wenn man Matlab nicht mit dem maxNumCompThreads-Kommando (s.u.) zurückhält, dann werdenMatlab alle Kerne benutzt, die es finden kann (und entsprechend viele Threads erzeugt).  Es könne also bis zu 160 Threads erzeugen werden, von denen jeder einzelne nicht viel zu tun hat. Der Overhead aber, um den Parallelismus zu verwalten, ist enorm und kostet richtig viel Zeit. Daher wird der Rechner den größten Teil der Zeit damit verbringen,  sich um den Parallelismus zu kümmern. Die eigentliche Berechnung steht nicht mehr im Vordergrund. Folge: Der Code läuft effektiv langsamer.

Man kann dieses Problem durch das Matlab-Kommando

maxNumCompThreads(<Anzahl gewünschte Threads>);

korrigieren.

Ein- und Ausgabeoprationen (I/O)

Helena nur eine NFS-Verbindung zu BIGWORK, die im Vergleich zu einer direkten Infiniband-Verbindung sehr langsam ist.  Schreibt oder liest man nun eine große Mengen an Daten, wird das Programm gebremst. Man ist u.U. auf einer anderen SMP Maschine mit Infiniband-Anbindung besser aufgehoben.

Aus all diesen Gründen hat Helena eine eigene Queue (helena) bekommen.

Wenn man merkt, dass man zu wenig Leistung auf Helena bekommt, aber trotzdem viel Hauptspeicher braucht (bis etwa 500 GB) sollte man den SMP-Cluster benutzen.  Dieser Cluster wird durch die folgende PBS-Option spezifiziert:

#PBS -W x=PARTITION:smp

Groß- und Kleinschreibung ist hier wichtig!  Die Queue-PBS-Anweisung ('-q') wird nicht mehr benötigt.

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 Fragezeichen 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:~$