Home >> Service >> Rechenanlagen >> LSF

English version available here

Verwaltung der Rechenressourcen mit LSF

Das Batchsystem Load Sharing Facility (LSF) der Firma Platform erlaubt es, alle Rechenressourcen der GWDG mit den gleichen Kommandos zu benutzen. Der Zugriff auf LSF kann von allen Rechnern aus erfolgen, auf denen bisher der Zugriff auf die Batchsysteme LSF, Codine oder den IBM Loadleveler möglich war. Dazu gehören die gwdu102 und die gwdk081, sowie neu die gwdu104, gwdu105 und gwds1. LSF ist so konfiguriert, dass die verschiedenen bei der GWDG zur Verfügung stehenden Rechnerarchitekturen eigenen Warteschlangen ("Queues") zugeordnet sind. Spezielle Anforderungen, wie größerer temporärer Plattenplatz oder mehr Hauptspeicher, werden dagegen nicht über Queues geregelt, sondern müssen vom Benutzer bei der Submittierung eines Jobs spezifiziert werden. Die zu einer Architektur gehörigen Rechner ("hosts") sind außerdem zu Gruppen ("hostgroups") zusammengefasst, wobei es zusätzliche Untergruppen von hosts mit besonderen Ressourcen gibt. Eine Übersicht über die LSF-Konfiguration gibt die folgende Tabelle.

Die hier vorliegende Dokumentation erklärt nur die für GWDG-Nutzer wichtigsten Aspekte von LSF, sowie die speziellen Eigenschaften der GWDG-Konfiguration. Weitere Informationen finden Sie in der englischen Nutzerdokumentation sowie in den manpages.

a) Syntax

bsub -q queuename -a wrapper -n nproc -M mem_in_kb -W hh:mm -m host -R resourcestring jobcommand
bsub < jobscript

b) Erläuterungen

Mit bsub können Jobs an LSF übergeben werden. Optionen können als Teil der Kommandozeile eingegeben werden, oder in einer Skriptdatei im Anschluss an die Auswahl der shell enthalten sein, wobei jeder Option ein #BSUB vorangestellt wird (siehe Beispiele). Die wichtigsten Optionen sind:

-q queuename

Mögliche Queuenamen können Sie der Übersichtstabelle entnehmen. Mit der Queue wird entsprechend dieser Tabelle auch die Architektur ausgewählt.

-a wrapper

Wrapper sind vorkonfigurierte Skripten, die die Submittierung von Paralleljobs erleichtern. Zur Zeit stehen folgende wrapper zur Verfügung:

• openmp für SMP Jobs
• scampi für MPI-Jobs in Queue gwdg-oppar
• mvapich_gc für MPI-Jobs in Queue gwdg-x64par (MVAPICH kompiliert mit GNU-Compiler)
• mvapich_ic für MPI-Jobs in Queue gwdg-x64par (MVAPICH kompiliert mit Intel-Compiler)
• mvapich2_gc für MPI-Jobs in Queue gwdg-x64par (MVAPICH2 kompiliert mit GNU-Compiler)
• mvapich2_ic für MPI-Jobs in Queue gwdg-x64par (MVAPICH2 kompiliert mit Intel-Compiler)
• openmpi_gc für MPI-Jobs in Queue gwdg-x64par (OpenMPI kompiliert mit GNU-Compiler)
• poe-p690 für MPI-Jobs in Queue gwdg-p690

Wenn vor dem eigentlichen MPI-Programm in einem Jobskript serielle Befehle abgearbeitet werden sollen, muss statt der -a Option direkt pam aufgerufen werden. In der Queue gwdg-x64par ist der direkte Aufruf von pam allerdings nicht mehr nötig (siehe Beispiele).

• "pam -g openmp_wrapper" für openmp Jobs
• "pam -g sca_mpimon_wrapper" für MPI-Jobs in Queue gwdg-oppar
• "pam -g mvapich_gc_wrapper" für MPI-Jobs in Queue gwdg-x64par (MVAPICH kompiliert mit GNU-Compiler)
• "pam -g mvapich_ic_wrapper" für MPI-Jobs in Queue gwdg-x64par (MVAPICH kompiliert mit Intel-Compiler)
• "pam -g mvapich2_gc_wrapper" für MPI-Jobs in Queue gwdg-x64par (MVAPICH2 kompiliert mit GNU-Compiler)
• "pam -g mvapich2_ic_wrapper" für MPI-Jobs in Queue gwdg-x64par (MVAPICH2 kompiliert mit Intel-Compiler)
• "pam -g openmpi_gc_wrapper" für MPI-Jobs in Queue gwdg-x64par (OpenMPI kompiliert mit GNU-Compiler)
• "pam -g 1 poe-p690" für MPI-Jobs in Queue gwdg-p690
• "pam -g 1 poe-p690-hybrid" für spezielle SMP/MPI Hybridjobs in Queue gwdg-p690

Für openmp und SMP/MPI Hybridjobs ist zusätzlich noch "LSF_PAM_HOSTLIST_USE=unique" zu exportieren.

-n nprocmin,nprocmax

Mit dieser Option wird die Zahl der Prozessoren angegeben. Ein Job läuft an, wenn mindestens nprocmin Prozessoren verfügbar sind und verwendet bis zu nprocmax Prozessoren. Nur ein Wert muss angegeben werden, er gilt dann für nprocmin und nprocmax. Beachten Sie bitte, dass auch für SMP- und Hybridjobs die Gesamtzahl der verwendeten Prozessoren angegeben werden muss, nicht die Zahl der Knoten.

-M mem_in_kb

Mit dieser Option können Mindest-Speicheranforderungen an die den Job ausführenden Knoten definiert werden. Nützlich ist dies auf der Altix (Queue gwdg-ia64), wo es Knoten mit 3 und 6 GB pro CPU gibt. Die Angabe erfolgt in KB pro CPU. Die Definition einer Mindest-Speicheranforderung mit -M ist nicht gleichzusetzen mit der Reservierung von Speicher-Ressourcen mit -R, die in Queue gwdg-p690 notwendig ist.

-W hh:mm

Die walltime, also die maximale Verweildauer im Status "run" des Jobs, in Stunden und Minuten. Höchstwerte für die jeweiligen Queues finden Sie in der Übersichtstabelle.

-m host

Hiermit können zulässige hosts für den Job definiert werden. Dies ist notwendig, wenn der Job spezielle Ressourcenanforderungen hat, die nicht von allen hosts einer Architektur gleich gut erfüllt werden können. Mehrere hosts werden in Anführungszeichen durch Leerzeichen getrennt angegeben ("host1 host2 host3"). Anstelle von host-Namen können auch hostgroups aus der Übersichtstabelle verwendet werden. Wichtige Anwendungsfälle für diese Option sind:

• Für mehr als 1 GB Hauptspeicher pro Prozessor in gwdg-p690 -m gwdk081

Gegebenenfalls sind hosts und hostgroups für schnellere Prozessoren innerhalb einer Architektur ebenfalls in der Übersichtstabelle aufgeführt, diese können aber auch über die Angabe des Modells im resourcestring (s.u.) spezifiziert werden.

-R resourcestring

Der resourcestring erlaubt die Zuteilung spezieller Ressourcen für den Job. Mehrere Ressourcenanforderungen werden in Anführungszeichen gefasst und durch Leerzeichen getrennt. Jede Anforderung hat die Syntax section[string]. section kann eines der Schlüsselwörter select, order, rusage, span und same sein. Mögliche Anwendungen für die GWDG Konfiguration sind:

select

Mittels des selectstrings kann in der Queue gwdg-p690 ("select[model=Power417]") eine schnellere CPU angefordert werden.

rusage

In der Queue gwdg-p690 muss mit "rusage[resmem=sizeofmem]" sizeofmem MB Hauptspeicher pro Prozessor reserviert werden. Hier wird bei mehr als 1000 MB pro Prozessor der host gwdk081 verwendet.

span

Mit "span[ptile=npn]" werden die insgesamt angeforderten Prozessoren in Blöcken der Größe npn auf die ausführenden hosts verteilt. Wenn alle Prozesse auf dem gleichen host alloziert werden sollen, muss npn gleich nproc (siehe -n Option) gewählt werden. Für die exklusive Nutzung eines hosts muss npn gleich der Zahl der auf dem host verfügbaren Prozessoren sein. Die exklusive Nutzung eines hosts mittels des -x Schalters wird nicht mehr unterstützt.

c) Beispiele

Jobs auf den Opteron Workstations (Queue gwdg-opser)

1. Anforderung von 24h auf einer CPU für das Programm serprog

        bsub -q gwdg-opser -W 24:00 serprog
       

2. Nutzung mehrerer (maximal 4) Prozessoren eines hosts für eine SMP-Anwendung, wie z.B. Gaussian im Parallelmodus. Der wrapper openmp (-a Option) sorgt dafür, dass das Programm nur einmal gestartet wird. -R span[ptile=4] alloziert alle vier Prozessoren (-n 4) auf demselben host - in der Queue gwdg-opser ist dies die Default-Einstellung, muss also eigentlich nicht noch einmal angegeben werden.

        bsub -q gwdg-opser -W 24:00 -a openmp -n 4 -R span[ptile=4] smpprog
       

3. Wie 2., aber mit einem Jobskript jobscript. Zudem wird hier ein OpenMP Programm gestartet, so dass zusätzlich die Variable OMP_NUM_THREADS exportiert werden muss.

        bsub < jobscript
       

   jobscript enthält:

        #!/bin/sh
        #BSUB -q gwdg-opser
        #BSUB -W 24:00
        #BSUB -n 4
        #BSUB -R span[ptile=4]
        
        export OMP_NUM_THREADS=4
        pam -g openmp_wrapper ompprog  
       

4. Auf dieselbe Weise lässt sich auch ein serielles Programm so starten, dass es einen Knoten exklusiv nutzt. Meist dient dies dazu, den gesamten Speicher des Knotens zu reservieren. Im folgenden Beispiel fehlt auch die -R span[ptile=4] Option, da sie für diese Queue default ist.

        bsub < jobscript
       

   jobscript enthält:

        #!/bin/sh
        #BSUB -q gwdg-opser
        #BSUB -W 24:00
        #BSUB -n 4
        
        serprog  
       

5. Ein Gaussian03 Job auf einem Prozessor kann mittels eines Skriptes (hier: g03lsf) submittiert werden:

         bsub < g03lsf
       

   g03lsf enthält:

         #!/bin/ksh
         #BSUB -q gwdg-opser
         #BSUB -W 48:00
   
         export g03root="/usr/product/gaussian"
         . $g03root/g03/bsd/g03.profile
         export GAUSS_SCRDIR="/scratch"
         g03 < input.com > output.log
       

   In dem Skript kann g03root auch auf "/usr/product/gaussian64" gesetzt werden:

         ...
         export g03root="/usr/product/gaussian64"
         ...
       

   Dadurch wird die 64-bit-Version von Gaussian ausgewählt. In den Queues gwdg-x64par und gwdg-ia64 ist die 64-bit-Version Standard und unter "/usr/product/gaussian" verfügbar.

Jobs auf dem Opteron-Cluster (Queue gwdg-oppar)

1. Anforderung von 24h auf mindestens 16 und höchstens 32 Prozessoren für das MPI-Programm mpiprog. Beim Starten wird der MPI-wrapper scampi verwendet.

        bsub -q gwdg-oppar -W 24:00 -a scampi -n 16,32 mpiprog
       

2. Wie 1., aber mit einem Jobskript jobscript

        bsub < jobscript
       

   jobscript enthält:

        #!/bin/sh
        #BSUB -q gwdg-oppar
        #BSUB -W 24:00
        #BSUB -n 16,32
   
        pam -g sca_mpimon_wrapper mpiprog  
       

Jobs auf dem Xeon64-/Woodcrest-Cluster (Queue gwdg-x64par)

1. Anforderung von 24h auf mindestens 16 und höchstens 32 Prozessoren für das MPI-Programm mpiprog. Beim Starten wird der MPI-wrapper mvapich_gc verwendet, wodurch die MVAPICH-Bibliothek (GNU-kompiliert) ausgewählt wird. Im Unterschied zu den älteren Architekturen wird zusätzlich ein zweiter Wrapper mpirun.lsf benötigt.

        bsub -q gwdg-x64par -W 24:00 -n 16,32 -a mvapich_gc mpirun.lsf ./mpiprog
       

2. Wie 1., aber mit einem Jobskript jobscript

        bsub < jobscript
       

   jobscript enthält:

        #!/bin/sh
        #BSUB -q gwdg-x64par
        #BSUB -W 24:00
        #BSUB -n 16,32
        #BSUB -a mvapich_gc
   
        mpirun.lsf ./mpiprog  
       

3. Wie 2., aber analog den älteren Architekturen mit direktem Aufruf von pam

        bsub < jobscript
       

   jobscript enthält:

        #!/bin/sh
        #BSUB -q gwdg-x64par
        #BSUB -W 24:00
        #BSUB -n 16,32
   
        pam -g mvapich_gc_wrapper ./mpiprog
       

Jobs auf der SGI Altix 4700 (Queue gwdg-ia64)

1. Anforderung von 24h auf mindestens 16 und höchstens 32 Prozessoren für das MPI-Programm mpiprog. Beim Starten wird direkt pam verwendet, einen Wrapper gibt es nicht.

        bsub -q gwdg-ia64 -W 24:00 -n 16,32 pam -mpi -auto_place ./mpiprog
       

2. Wie 1., aber mit einem Jobskript jobscript. Außerdem werden hier Knoten mit mindestens 6 GB pro CPU angefordert.

        bsub < jobscript
       

   jobscript enthält:

        #!/bin/sh
        #BSUB -q gwdg-ia64
        #BSUB -W 24:00
        #BSUB -n 16,32
        #BSUB -M 6000000
   
        pam -mpi -auto_place ./mpiprog  
       

3. Nutzung mehrerer Prozessoren (maximal 256 sind möglich) eines hosts für eine SMP-Anwendung. Der wrapper openmp (-a Option) sorgt dafür, dass das Programm nur einmal gestartet wird. Da es sich hier um ein OpenMP-Programm handelt, muss die Variable OMP_NUM_THREADS exportiert werden.

        bsub -q gwdg-ia64 -W 24:00 -a openmp -n 64 env OMP_NUM_THREADS=64 ./ompprog
       

4. Wie 3., aber mit einem Jobskript jobscript. Außerdem werden hier 32 CPUs mit mindestens 6 GB pro CPU angefordert.

        bsub < jobscript
       

   jobscript enthält:

        #!/bin/sh
        #BSUB -q gwdg-ia64
        #BSUB -W 24:00
        #BSUB -n 32
        #BSUB -M 6000000
        #BSUB -a openmp
        
        export OMP_NUM_THREADS=32
        ./ompprog
       

Jobs auf der IBM pSeries 690 (Queue gwdg-p690)

1. Anforderung von 24h auf einer CPU mit 1 GB Hauptspeicher (rusage[resmem=1000]) für das Programm serprog. Der benötigte Hauptspeicher muss in Queue gwdg-p690 immer angegeben werden.

         bsub -q gwdg-p690 -W 24:00 -R rusage[resmem=1000] serprog
       

2. Anforderung von 24h auf 16 Prozessoren (-n 16) mit 1 GB Hauptspeicher pro Prozessor, also 16 GB Hauptspeicher insgesamt, für das SMP Programm smpprog. -a openmp verwendet den openmp wrapper zum Starten des Programms. Er ist auch für nicht mit OpenMP parallelisierte SMP Programme geeignet.

         bsub -q gwdg-p690 -W 24:00 -a openmp -n 16 -R rusage[resmem=1000] smpprog
       

3. Wie 2., aber mit 2 GB Hauptspeicher pro Prozessor. Bei mehr als 1 GB pro Prozessor muss die gwdk081 verwendet werden (-m Option).

         bsub -q gwdg-p690 -W 24:00 -m gwdk081 -a openmp -n 16 -R rusage[resmem=2000] smpprog
       

4. Wie 3., für ein OpenMP Programm

         bsub -q gwdg-p690 -W 24:00 -m gwdk081 -a openmp -n 16 -R rusage[resmem=2000] \
         env OMP_NUM_THREADS=16 ompprog
       

5. Wie 4., aber mit einem Jobskript jobscript

         bsub < jobscript
       

   Das Jobskript jobscript enthält:

         #!/bin/sh
         #BSUB -q gwdg-p690
         #BSUB -W 24:00
         #BSUB -m gwdk081
         #BSUB -n 16
         #BSUB -R rusage[resmem=2000]
   
         export LSF_PAM_HOSTLIST_USE=unique
         export OMP_NUM_THREADS=16
         pam -g openmp_wrapper ompprog
       

   Die im Skript gesetzte Variable OMP_NUM_THREADS gibt für OpenMP Programme die Zahl der zu erzeugenden threads und damit die Zahl der genutzten Prozessoren an. Sie sollte immer gleich der mit der bsub Option -n angeforderten Prozessorenzahl sein. Nur OpenMP Programme erfordern und berücksichtigen diese Variable.
6. Start eines MPI-Programms auf 16 Prozessoren. Hier wird der poe-wrapper poe-p690 verwendet, der auch die passende Queue wählt. Die Optionen nach dem Programmnamen mpiprog (und möglichen, hier nicht vorhandenen Programmoptionen) werden an poe übergeben. Die poe Option -shared_memory yes wählt die schnelle shared memory Kommunikation für Prozesse auf dem gleichen host.

         bsub -a poe-p690 -n 16 -R rusage[resmem=500] mpiprog -shared_memory yes
       

7. Wie 5., aber mit einem Jobskript jobscript

         bsub < jobscript
       

   Das Jobskript jobscript enthält:

         #!/bin/sh
         #BSUB -q gwdg-p690
         #BSUB -n 16
         #BSUB -R rusage[resmem=500]
   
         pam -g 1 poe-p690 mpiprog -shared_memory yes
       

a) Syntax

bjobs -l -a -r -p -u uid -m host jobid

b) Erläuterungen

Mit bjobs kann der Status eines Jobs angezeigt werden. Wenn keine jobid angegeben wird, werden alle mit den gewählten Optionen übereinstimmenden Jobs angezeigt.

-l

Zeigt die ausführliche Statusbeschreibung eines Jobs.

-a -r -p

-a zeigt laufende (RUN), wartende (PEND) und kürzlich beendete Jobs an. Standardmäßig werden nur laufende und wartende Jobs angezeigt. -r zeigt nur laufende Jobs, -p nur wartende Jobs plus die Ursachen f�r die Wartezeit.

-u uid

Es werden die Jobs von Nutzer uid angezeigt. Ohne Angabe werden die eigenen Jobs angezeigt. Mit uid=all werden die Jobs aller Nutzer angezeigt.

-m host

Es werden nur Jobs angezeigt, die auf den angegebenen hosts oder der hostgroup laufen. Mehrere hosts oder hostgroups werden durch Leerzeichen getrennt in Anführungszeichen angegeben (z.B. -m "gwdl001 hgroupwk")

c) Beispiele

1. Anzeigen aller laufenden Jobs von Nutzer xyz auf dem Woodcrest-Cluster

      bjobs -r -u xyz -m hgroupx64
    

a) Syntax

bkill -r -u uid -m host -q queue jobid

b) Erläuterungen

Mit bkill kann ein laufender Job abgebrochen oder ein wartender Job aus der Warteschlange entfernt werden. Wenn keine jobid angegeben wird, muss eine der Optionen -u -m -q verwendet werden. Betroffen ist dann der letzte Job, auf den die angegebenen Kriterien zutreffen. Die Angabe von jobid=0 führt zur Anwendung auf alle Jobs, die den jeweiligen Kriterien entsprechen.

-r

Entfernt einen Job aus der Warteschlange, ohne auf die Bestätigung des Betriebssystems zu warten, dass der Job beendet ist. Nur für Fälle, in denen ein Job anders nicht zu entfernen ist.

-u uid -m host -q queue

Mit diesen Optionen werden Kriterien festgelegt, nach denen bkill auf Jobs angewendet wird. -u uid betrifft Jobs des Nutzers uid (nur Administratoren können Jobs anderer Nutzer entfernen), -m host Jobs auf dem angegebenen host oder der hostgroup und -q queue Jobs der angegebenen Queue. Ohne Angabe einer jobid wirkt bkill auf den letzten, mit jobid=0 auf alle passenden Jobs. Bei allen anderen Angaben für jobid sind diese Optionen wirkungslos.

c) Beispiele

1. Entfernen des Jobs 14444

         bkill 14444
       

2. Entfernen aller Jobs in der Queue gwdg-x64par, die auf host gwdm111 laufen

         bkill -m gwdm111 -q gwdg-x64par 0
       

a) Syntax

bhosts -l -w host

b) Erläuterungen

Mit bhosts werden Informationen über den host oder die hostgroup host abgefragt.

-l -w

-l und -w steuern die Ausgabe. -w erzeugt eine gegenüber dem Standard etwas erweiterte Ausgabe, bleibt aber bei einer Zeile pro host. -l ergibt eine ausführliche mehrzeilige Ausgabe pro host.

c) Beispiele

1. Erweiterte Einzeilendarstellung aller hosts

         bhosts -w
       

2. Ausführliche Mehrzeilendarstellung der hosts gwdm001, gwdm002, gwdm003

         bhosts -l gwdm001 gwdm002 gwdm003
       

"command not found" oder ähnliches bei Verwendung von LSF-Kommandos

Die zu LSF gehörigen Umgebungsvariablen wurden nicht richtig gesetzt. Sie können dies in der Kommandozeile tun. Für ksh und bash lautet der Befehl

      . /opt/hplsf/conf/profile.lsf
    

Für csh und tcsh:

      source /opt/hplsf/conf/cshrc.lsf
    

Bei Submission mittels Jobskript werden "#BSUB ..." Zeilen nicht beachtet

Sie submittieren ein völlig korrektes Jobskript, aber LSF ignoriert die mittels "#BSUB ..." gesetzten Optionen. Zum Beispiel landet der Job in der default Queue gwdg-pcpar statt in der mit "#BSUB -q" gewählten Queue. Dies liegt sehr oft daran, dass das kleiner-als-Zeichen < bei der Submission vergessen wurde. Richtig muss es wie folgt aussehen:

      bsub < jobscript
    

Jobs starten nicht, Zustand bleibt PEND

Hierfür gibt es mehrere mögliche Ursachen:

• Für den Zugang zu den Linux-basierten Ressourcen (pc(par/ser), op(par/ser), x64par, ia64) muss Ihre Nutzerkennung zunächst freigeschaltet werden. Bitte wenden Sie sich hierfür an support@gwdg.de.
• Es wurde eine Ressource angefordert, die nicht vorhanden ist. Dies kann beispielsweise vorkommen wenn ein Skript für die Queue gwdg-p690 für eine andere Queue modifiziert, und dabei der -R rusage[resmem=...] Parameter beibehalten wird.
• Die Queue wurde für Wartungsarbeiten deaktiviert. Dies kann mit dem Kommando bqueues überprüft werden.

Gaussian-Jobs brechen sofort ab. Im Output findet sich die Meldung "Permission denied"

Für die Nutzung von Gaussian wird zusätzlich zur Freischaltung für die Linux-Ressourcen eine weitere für die Gaussian-Nutzergruppe benötigt. Für letztere senden Sie bitte eine Email mit einer wenige Zeilen langen Beschreibung Ihres Projektes und seines geplanten Umfanges (Anzahl der Rechnungen, Methoden, Anzahl der Basisfunktionen, o. ä.) an: cboehme1@gwdg.de.

Fehlende Bibliotheken bei Submittierung zwischen verschiedenen Architekturen

Wenn von einer Architektur auf eine andere submittiert wird - z.B. von der gwdu102 (x86-Linux) in die gwdg-ia64 Queue (ia64-Linux) - kann es zu Fehlermeldungen bezüglich fehlender Bibliotheken kommen. Bitte submittieren Sie in diesem Fall von derselben Architektur, die auch Ziel für die Ausführung des Jobs ist, und teilen Sie uns das Problem mit.

Programm 'hängt' bei Verwendung einer STDIN-Umleitung

Wenn mittels des < Zeichens eine Datei in den STDIN Strom eines Programms eingelesen wird, bleibt dieses stehen. Dieses Problem tritt bei Submittierung mit der -a openmp Option auf. Verwenden Sie in dem Fall cat zum Bilden einer Pipe, also

      bsub -a openmp ... 'cat inputfile | smpprog'
    

statt wie bisher

      bsub -a openmp ... smpprog < inputfile
    

Dies gilt analog auch für Skripten.