Das Batchsystem TORQUE und der Scheduler Maui

Zurzeit sind drei Execution-Queues (testq, smallq, bigq) und eine Routing-Queue (default) konfiguriert. Die jeweils aktuelle Konfiguration des Batch-Servers und der Queue kann man mit dem Befehl

qmgr -c "print server"

abfragen.

Die aktuelle TORQUE-Konfiguration

Batch Jobs

Ein Beispiel für ein PBS-Skript (beispiel.pbs), hier ein Single-Prozessor-Job:

#PBS -o /home/u/username/output.dat
#PBS -l walltime=2:00:00,nodes=1,nice=19
#PBS -M username@uni-muenster.de
#PBS -m ae
#PBS -q default
#PBS -N Jobname
#PBS -j oe

cd $PBS_O_WORKDIR
./a.out

Die Zeilen bedeuten: 

  1. Name der Standard-Ausgabedatei
  2. erwartete Rechenzeit (2 Stunden), Anzahl der Knoten (hier: 1 Core auf einem beliebigen Rechenknoten),  Nice-Level
  3. E-Mail Adresse des Benutzers
  4. E-Mail Benachrichtigung bei Job abort und end
  5. Name der Queue. In diesem Fall (default) wird anhand der Walltime entschieden, in welcher Queue der Job landet (nämlich in der testq)
  6. Name des Jobs
  7. Zusammenführen von Standard-Output und Standard-Error in eine einzige Datei
  8. In das Verzeichnis wechseln, in dem das Submitskript abgeschickt wurde
  9. Aufruf des kompilierten Programmes, Shellskripts etc.

Job-Monitoring

Zur Diagnose eigener Rechenjobs kann das Utility pbstop verwendet werden.

Die Auswahl der Rechenknoten

Mit der Option -l legt man die Ressourcenanforderungen für den Batch-Job fest. Bei der Festlegung der Anzahl und Art der Nodes ist zu beachten, dass die Rechenknoten des Systems zur Unterscheidung mit den Eigenschaften "smp" (zivsmp001) und "hpc" (node001 bis node020) gekennzeichnet sind. Außerdem gibt es pro Node mehrere CPU-Kerne, so dass die Angabe nodes zwei unterschiedliche Bedeutungen haben kann. Die folgende Tabelle soll verdeutlichen, wie sich die Angabe nodes auf die Auswahl der Rechenknoten auswirkt:

Angabe im Batch-Job Auswahl der Rechenknoten
Sinnvolle Angaben
-l nodes=1:smp:ppn=6 6 Cores auf zivsmp001
-l nodes=1:hpc:ppn=8 8 Cores genau eines HPC-Knotens (z.B. node016). Nur diese Art der Ressourcenanforderung stellt sicher, dass der Rechenjob exclusiv auf einem 8-Core-Knoten läuft, ohne von anderen gestört zu werden.
-l nodes=node016:ppn=8 Explizite Auswahl des Knotens node016 mit allen 8 Cores
Nicht empfehlenswerte oder fehlerhafte Zuteilungen
-l nodes=10 10 beliebige CPU-Kerne  von zivsmp001 oder einem der HPC-Knoten. Auch gemischte Zuteilung möglich. Keine gute Idee
-l nodes=2:smp:ppn=4 keine Zuteilung, da es nur 1 System mit der Eigenschaft "smp" gibt.
-l nodes=192 Auswahl aller Cores des Gesamtsystems (nur in der Queue testq erlaubt)
-l nodes=8:hpc:ppn=1 Fehlerhafte Zuteilung. Die Anzahl von ppn, wenn angegeben, sollte größer oder gleich 2 sein. Aufgrund eines Bugs in TORQUE erhält man für ppn=1 nicht das erwartete Ergebnis, sondern z.B. in diesem Fall 8 willkürlich über die HPC-Rechnenknoten verteilte Cores.

Anmerkungen zur Rechenzeit

Bei der Anforderung von Ressourcen kann die erwartete Rechenzeit mit der Angabe walltime begrenzt werden. Dabei ist folgende Regel zu beachten, nach welcher der Scheduler Maui entscheidet, welche Jobs gestartet werden:

Ein Benutzer kann zu jedem Zeitpunkt maximal 2560 noch abzuarbeitende Stunden Rechenzeit in seinen laufenden Jobs vereinigen. Das entspricht einem 160-Stunden-Job (in der Queue "bigq" erlaubt) auf genau 16 Cores, also zwei kompletten HPC-Knoten.

Natürlich können diese 2560 Stunden auf mehrere Jobs verteilt sein. Nehmen wir als Beispiel den 160-Stunden-Job auf 16 Cores, den der Nutzer angefordert hat mit der Angabe

-l nodes=2:hpc:ppn=8,walltime=160:00:00

Sobald dieser Job gestartet wird, hat der Benutzer seine Schranke von 2560 Stunden (=16 x 160) erreicht. Dem Benutzer fällt dann ein, dass er noch schnell einen 1-Stunden-Job auf 8 Cores (1 HPC-Knoten) in der Queue "testq" rechnen möchte, und schickt einen entsprechenden Job mit der Angabe

-l nodes=1:hpc:ppn=8,walltime=1:00:00

direkt hinter dem ersten Job ab. Natürlich kann dieser Job, der insgesamt mit 8 Stunden Rechenzeit zu Buche schlägt, nicht sofort loslaufen. Dazu muss erst der andere Job soweit abgearbeitet sein, dass er nur noch 2552 ausstehende Stunden Rechenzeit übrig hat. Dies ist bei 16 Cores nach einer halben Stunde der Fall. Der Benutzer muss also mindestens 30 Minuten warten, bevor der zweite Job eine Chance erhält, gestartet zu werden. Das gibt aber natürlich Jobs anderer Benutzer in der Zwischenzeit Gelegenheit, selbst zu starten. Auf diese Weise soll eine gerechtere Verteilung der Rechenzeit erreicht werden, da niemand auf Dauer mehr als 10 Prozent der HPC-Knoten belegen kann. Trotzdem kann man aber für kürzere Zeiträume sehr viele Knoten belegen, z.B. in der Queue "smallq" alle 160 HPC-Cores für 16 Stunden. Ob man sich damit bei anderen Nutzern beliebt macht, steht auf einem anderen Blatt ...