Hinweise zum Batch-System auf dem Linux-Cluster "CLUH"

Zur Abgabe von Batch-Jobs steht auf dem Linux-Cluster das Batchsystem Sun Grid Engine (SGE) zur Verfügung. Batchjobs werden dabei als Shellscript vorbereitet. Dieses Shellscript muss x-Permission haben. Optionen für den Batchbetrieb werden innerhalb dieses Shellscripts durch #$ eingeleitet.

Hier ein paar nützliche Optionen:

   #$  -S /bin/ksh             Shell: ksh (default)

   #$ -o <path>                Dateiname für die Standardausgabe (stdout)
   #$ -e <path>                Dateiname für die Standardfehlerausgabe (stderr)

   #$  -j y                    Join: Standardfehlerausgabe wird in Standardausgabe geschrieben

   #$  -N jobname              Default: Dateiname (qsub)

Ressourcenbedarfe, wie CPU-Zeit, sollten generell angegeben werden, damit ein gutes Scheduling durchgeführt werden kann.

   #$ -l resource=value        für Resourcen-Beschränkung, z.B.
   #$ -l h_cpu=00:30:00        für 30 Minuten-Job (hardlimit). 

                               Max: 100 Std.

   #$ -l s_cpu=0:28:00         Abbruch nach 28 Minuten (softlimit),

                               es bleibt noch Zeit bis zum hardlimit,

                               um Restaufgaben zu erledigen, wie temporäre Dateien löschen.

Die Restaufgaben können in einem .epifile definiert werden. Man kann dieses auch übersteuern durch einen eigenen trap, wie z.B.:

       trap Kommando EXIT oder trap "rm /tmp/* " EXIT

Weitere Optionen:

   #$ -cwd                     Wechseln in das Verzeichnis, aus dem der Batchjob aufgerufen wurde.

   #$ -m e,b,a                 Mail nach Ende,Beginn,Abbruch des Batch-Jobs
   #$ -M mailadresse           Benachrichtigung über E-Mail.

   #$ -v Variable=Wert         Umgebungsvariablen setzen. Kann notwendig sein, damit Umgebungs-
                               variablen auch an parallele Prozesse vererbt werden.

   #$ -w v                     Job überprüfen, aber nicht abschicken.

Beispiel für SGE-Optionen für serielle (nicht parallele) Jobs

   #$ -S /bin/bash
   #$ -j y
   #$ -cwd
   #$ -l h_cpu=01:00:00
   #$ -m ea
   #$ -M name@rrzn.uni-hannover.de
  time ./a.out

SGE-Optionen für MPI-Jobs

 

Es sind zwei parallele Umgebungen "mpi" und "mpi2" definiert.

mpi       für          MPI-1

mpi2     für          MPI-2

 

Diese können wie folgt benutzt werden.

   #$ -pe mpi  8

bzw.

   #$ -pe mpi2 8

 8 Prozessoren werden angefordert

 

   #$ -pe mpi  2-32

bzw.

   #$ -pe mpi2 2-32

2 bis 32 Prozessoren werden angefordert, abhängig davon, wieviel gerade frei sind.

Es werden Umgebungs-Variablen gesetzt, die man in einem mpirun-Kommando bzw. mpiexec-Kommando verwenden muss:

   $NSLOTS                     Anzahl der zugeteilten Prozessoren
   $TMPDIR/machines            Maschinenliste der zugeteilten Prozessoren.

   $PORT                       Port für die MPI-2-Kommunikation, wird nur für "mpi2" berechnet.

Dieses kann wie folgt benutzt werden:

MPI-1:

   module load mvapich-pgi         # Initialisierung der MPI-Umgebung
   mpirun -machinefile $TMPDIR/machines -np $NSLOTS ./a.out

MPI-2:

   module load mvapich2-pgi       # Initialisierung der MPI-2-Umgebung

   mpiexec -machinefile $TMPDIR/machines -n $NSLOTS -port $PORT ./a.out

SGE-Optionen für Shared-Memory-Jobs

   #$ -pe shm 4      Es werden 4 Prozessoren auf einem Knoten angefordert.
                     Diese Option kann auch für MPI-Jobs verwendet werden,
                     die auf 1 Knoten laufen sollen.

SGE-Kommandos

Batch-Job abschicken:

    qsub batch.sh

Obige Optionen können auch im qsub-Kommando angegeben werden, z.B.

    qsub -l h_cpu=0:10:00 batch.sh

Einen Job zu einem ausgewählten Knoten schicken:

    qsub -q all.q@lcn10.rrzn.uni-hannover.de  batch.sh

Ein Batch-Auftrag muss nicht unbedingt ein Shell-Skript sein.

Einen Binär-Job abschicken:

    qsub -b y -l h_cpu=0:45:00 -cwd ./a.out

Status-Abfrage:

    qstat

   oder ausführlicher

    qstat -f  

   oder für einen Job

    qstat -j jobid

Mit qstat -j kann man herausfinden, warum ein Job in der Warteschlange verweilt.

Mit

    qstat -g c

erhält man einen Überblick über die Anzahl der belegten bzw. freien CPUs.

Attribute eines wartenden Jobs ändern:

     qalter

Beispiel:

Zeitlimit auf 100 Stunden setzen

     qalter -l h_cpu=360000 jobid

Job beenden:

    qdel jobid

    qdel -u username       alle Jobs eines Users

Accounting-Daten:

Nach Beendigung eines Jobs kann man sich mit

    qacct -j jobid

die Accounting-Daten ansehen.

 

Resource Quotas:

Man kann in der Grid Engine Resourcen quotieren, beispielsweise kann man die Anzahl der Slots pro Benutzer limitieren. Mit dem Kommando

     qquota

werden die verbrauchten Resourcen und die Limits angezeigt. 

Grafisches Benutzer Interface:

Wer nicht mit diesen Kommandos arbeiten will, kann ein grafisches Tool benutzen:

    qmon

Weitere Informationen finden Sie auf den man-Pages.

 

Lokale Konfigurierungen der Grid Engine am RRZN (CLUH):

Es werden normalerweise bis zu 8 Jobs und bis zu 36 Cpus pro Benutzernamen gleichzeitig bearbeitet. Bei Bedarf werden diese Werte verändert.

 

Mit der booleschen Ressource "notshared" kann man erreichen, dass ein Job nur auf vollständig freien (nicht auch von anderen Jobs benutzten)  Knoten  abläuft.

Beispiel:

     qsub -l notshared -pe mpi 8  jobscript

Dieser Job läuft exklusiv auf 2 Knoten, dadurch stört bzw. wird er nicht durch andere Jobs gestört z.B. bei sehr hohen Speicheranforderungen.

Da die Umgebungsvariable TMPDIR jetzt immer auf das lokale /tmp eines Knoten zeigt, steht für grosse Scratch-Dateien das Dateisystem /bigtmp zur Verfügung. Für jeden Job wird in /bigtmp ein Unterverzeichnis angelegt, welches nach Beendigung des Jobs mit allen darin enthaltenen Dateien automatisch gelöscht wird.

Zugriff erhält man, indem man in seinem Job

    export BIGTMP=/bigtmp/$(basename $TMPDIR)

definiert und dann dort seine Scratchdateien anlegt.

 

Einen Link zu allen man-Pages der Grid Engine findet man hier.