Aus Sicht des Systemadministrators ist die Verwendung eines Queuing Systems
von Vorteil, da auf diese Weise eine gezieltere Verwaltung von CPU-Resourcen
möglich ist, als das ohne Queues der Fall wäre.
Für den Benutzer ist insbesondere die transparente Verteilung
auf freie Rechner interessant.
Lokale Konfiguration
Auf dem CHEMnet sind folgende Klassen von Queues installiert:
Allgemein zugängliche Rechner campher(*) long:-/48/48/32 normal:5/24/24/24 citral(*) long:-/48/48/32 normal:5/24/24/24 cystein long:-/80/80/64 normal:5/24/24/24 glycin long:-/48/48/32 normal:5/24/24/24 klee long:-/128/128/128 normal:5/24/24/24 leucin long:-/48/48/32 normal:5/24/24/24 linus(*) long:-/64/64/48 normal:5/24/24/24 lysin long:-/64/64/48 normal:5/24/24/24 nerol long:-/64/64/48 normal:5/24/24/24 phytol(*) long:-/32/32/24 normal:5/24/24/24 pinen(*) long:-/64/64/48 normal:5/24/24/24 rabbit(*) long:-/64/64/48 normal:5/24/24/24 serin long:-/64/64/48 normal:5/24/24/24 valin long:-/64/64/48 normal:5/24/24/24 wilson long:-/64/64/48 normal:5/24/24/24 *: diese Rechner sind eigentlich bestimmten Instituten zugeordnet, wurden aber der Allgemeinheit zugänglich gemacht AGs Engelhardt, Hartl, Seppelt, Hahn, Marx blume(*) long:-/64/64/48 normal:5/24/24/24 AG Bradaczeck kratky long:-/-/-/48 normal:5/24/24/24 AG Knapp bose long:-/-/-/- normal:5/24/24/24 debye long:-/-/-/48 normal:5/24/24/24 dirac long:-/32/32/32 normal:5/24/24/24 einstein long:-/-/-/- normal:5/24/24/24 fermi long:-/32/32/32 normal:5/24/24/24 maxwell long:-/32/32/32 normal:5/24/24/24 waller long:-/-/-/48 normal:5/24/24/24 AG Limbach carotin long:-/-/-/48 normal:5/24/24/24 AG Luger ewald long:-/-/-/48 normal:5/24/24/24 luca long:-/64/64/48 normal:5/24/24/24 marie long:-/64/64/48 normal:5/24/24/24 AG Manz lynx long:-/-/-/196 normal:5/24/24/24 AG Saenger crick long:-/64/64/48 normal:5/24/24/24 fractal long:-/64/64/48 normal:5/24/24/24 hodgkin long:-/64/64/48 normal:5/24/24/24 kendrew long:-/48/48/32 normal:5/24/24/24 patterson long:-/-/-/48 normal:5/24/24/24 perutz long:-/-/-/48 normal:5/24/24/24
long_x oder normal_x,
auf einem Rechner mit Scratchplatte schicken. (Und diese dann auch benutzen.)
Welche Rechner eine eigene
Scratchplatte besitzen, kann mit dem Befehl z -df | grep scratch
ermittelt werden.
normal Queue schicken.
long Queue schicken.
qsub-Kommando)
oder im Skript ('# QSUB'-Direktive) den benötigten
Speicherbedarf angeben. Dann erst
von einem beliebigen Rechner aus in die long Queue schicken.
Achtung: Wenn man die Angabe des benötigten Speicherbedarfs unterläßt, muß man damit rechnen, daß der Job in einer Queue ausgeführt wird, die weniger Speicher als erforderlich zur Verfügung stellt. In diesem Fall würde der Job während der Ausführung abgebrochen.
qsub(1)
verwendet.
Neben einer Reihe von optionalen Flags erwartet dieser Befehl die Angabe
eines script-files. Dabei handelt es sich in der Regel um ein sh script,
sofern nicht mit dem üblich '#!' Mechanismus für
eine andere shell gesorgt wird. Es empfiehlt sich aber (safety first),
auch für den Standardfall mit der Zeile #!/bin/sh zu
beginnen.
Neben der der Angabe auf der Kommandozeile können auch im Skriptfile Optionen gesetzt werden:
#!/bin/sh # QSUB -q long # in diese Queue schicken (pipe-queue) # QSUB -ld 40MB # nur in Queues abarbeiten, die mindestens # 40MB data-segment size bieten # QSUB -me # bei Beendigung des Jobs eine Mail schicken # # QSUB # end of flags ... Der so abgeschickte File bewirkt (im Gegensatz zum direkten Aufruf !) bei seiner Ausführung einen login-Vorgang. Daraus ergeben sich im wesentlichen zwei Dinge:
cd(1)
Befehl einfügen. Als Hilfe stellt NQS die environment variable
QSUB_WORKDIR zur Verfügung.
Ein einfaches NQS script könnte also so aussehen:
#!/bin/sh cd $QSUB_WORKDIR mein_feines_programm -mit -optionen
.cshrc und .profile darf
nicht davon ausgegangen werden, daß der Standard-Input von einem
Terminal kommt. Befehle wie z.B.
stty(1)
führen zu Fehlermeldungen. Im Extremfall kann es aber auch zum
Abbruch kommen.
Zum Auflisten von NQS Jobs dient der Befehl
qstat(1).
Mit dem Befehl
qdel(1)
kann man wartende NQS Jobs löschen oder (zusammen mit dem Flag
-k) in Ausführung befindliche Jobs abbrechen.
Dieser Befehl erwartet die Angabe einer request-id. Dabei ist
zu beachten, dass die I.D., die in der Standardform des qstat
Kommandos ausgegeben wird unvollständig ist. Es wird dabei nur der
numerische Teil gezeigt. Um die vollständige request-id (die auch
den Namen des Hosts enthält, von dem der Job abgeschickt wurde) zu
erhalten, kann man z.B. qstat mit der Option -s aufrufen.
Load Balancing
Für Queues, die über ein load balancing verfügen (normal, long),
werden Jobs in einer zentralen Queue (queue_s@bragg)
gehalten,
bis sie auf einer der beteiligten Ziel-Queues (queue_x)
starten können. Falls mehrere freie Queues zur Wahl stehen,
wird der Rechner mit der geringsten Gesamtbelastung gewählt.
Möchte man einen Job auf einem bestimmten Rechner ausführen lassen,
muß auf diesem die Queue queue_x benutzt werden.
Remote Queues
Neben den lokalen Queues auf dem CHEMnet ist eine Queue abacus
eingerichtet, die das Abschicken von Batch-Jobs auf den
Compute-Server der
ZEDAT
gestattet. Hierbei wird nur die Default-Queue des Compute-Servers
angesprochen;
andere Queues des Compute-Servers können nur lokal bedient werden.
Es gelten die folgenden Parameter:
CPU-Zeit: max. 2500 h Hauptspeicher: max. 256 Mb Anz. Prozessoren: 1Abschicken des Jobs wie üblich mit dem Kommando
qsub -q abacus {script}
Übersicht der Jobs auf dem Compute-Server:
qstat -a @abacus.zedatACHTUNG: Die Home-Directory eines Benutzers heißt am Compute-Server /home/{name}, am CHEMnet heißt diese Directory /work/{name}. In den Scripts für die Batch-Jobs, die auf abacus gerechnet werden sollen, muß immer der am Compute-Server gültige Name verwendet werden!
Filesysteme des CHEMnet können vom Compute-Server aus nicht angesprochen werden!