HTCondor

Aus Physik
Zur Navigation springen Zur Suche springen

Was ist HTCondor?

HTCondor ist ein verteiltes Batchsystem, das uns ermöglicht, die am Institut vorhandenen Computer-Resource soweit möglich zu nutzen. HTCondor unterstützt das High Throughput Computing (HTC), das im Gegensatz zum High Performance Computing (HPC) nicht auf möglichst kurze Antwortzeiten für Einzelaufgaben zielt, sondern die verfügbare Leistung fair und effizient auf alle Benutzer aufteilt.

Weitere Informationen finden Sie in einem älteren Artikel.

Wir haben die nötigen Libraries fürs High Performance Computing zwar installiert, aber unser Computernetz ist für diese Art von Rechnungen nicht optimiert. Besser Sie entwickeln und testen ihre Programme am Institut und verwenden für die produktiven Läufe die dedizierten Cluster des Zentralen Informatikdienstes.


Benutzung

Die wichtigsten Befehle sind:

  • condor_status - Status der Rechner im Condor-Pool
  • condor_submit - Starten von Batchjobs
  • condor_q -global - Anzeige der laufenden bzw. wartenden Programme

Leider haben nicht alle Programme der HTCondor-Suite Manual Pages; aber alle reagieren auf die Option -h mit kurzer Hilfestellung. Sie finden die komplette Dokumentation im Internet.

Bitte beachten Sie unbedingt, daß das System nur für Aufgaben ab einer bestimmten Mindestlaufzeit von einigen Minuten effizient arbeitet, weil ein nicht unbeträchtlicher Verwaltungsaufwand zum Starten der einzelnen Jobs anfällt und die File-Server bei kurzen Programmlaufzeiten unter Umständen wesentlich belastet werden.

Zugriff auf das Homedirectory

Zugriff aufs Homedirectory ist nur mit einigen Klimmzügen möglich, weil alle Prozesse unter Condor vom Submitter getrennt werden und die Zugangsberechtigung zum AFS daher nicht "erben" können. Wir haben daher eine Alternative zu den Homedirectories#Ausweichmöglichkeiten: /temp/ kann wie ein lokales, temporäres Verzeichnis genutzt werden; liegt aber auf einem Cluster von Servern (MooseFS) und ist aus dem gesamten Netz des Instituts bzw. Computerraums zugänglich.

Parallele Prozesse

Es gibt seit kurzem die Möglichkeit, mehrere CPUs für einen Slot (Vergabe-Einheiten, Rechenknoten) dynamisch anzufordern. Das ist gut geeignet für parallele Prozesse auf einer Maschine (OpenMP, Verwendung paralleler Bibliotheken wie libsuitesparse oder ALPS); es ist nicht bzw. wenig brauchbar für parallele Prozesse auf mehrereren Maschinen (MPI, PVM, ...)

Zur Verwendung werden in der Submit-Datei die Anforderungen für den Prozess definiert: 

 request_cpus   = 2
 request_memory = 128
                # MiBytes
 request_disk   = 512
                # kiBytes

Die Funktion wird mit dynamisch partitionierten Slots realisiert, deshalb ist die Grafik der mittleren Auslastung bei der Anzahl der insgesamt vorhandenen Rechenknoten stark schwankend.

Effiziente Programme

Neben den allgemeinen Ursachen für ineffizient laufende Programme kommen mit der Verwendung von Batchsystemen einige zusätzliche Punkte:

unpassende Algorithmen 
sind leider manchmal nicht zu vermeiden. Häufig kann auf externe Libraries zurückgegriffen werden, die wesentlich besser optimiert wurden als Selbstgeschriebenes.
Swappen 
Exzessives Auslagern von Daten aus dem Hauptspeicher auf die Festplatte ist eine der schlimmsten Bremsen für die Ablaufgeschwindugkeit ünberhaupt. Geben sie in der Submit-Datei den Speicherbedarf ihres Programms in der Variable ImageSize an, damit Condor einen Rechner mit dem nötigen Resource finden kann. Die verwendete Einheit ist 1MByte. Sie erhalten die notwendige Größe aus top; verwenden sie die Werte aus der Spalte RSS.
Überlastung der File-Server
Durch den Start vieler Instanzen des selben Programms kann es sehr leicht zu einem Engpass auf den Dateiservern kommen. Ein Beispiel aus der Praxis:
Es werden 300 Jobs gestartet, die eine durchschnittliche Laufzeit von 3 Minuten haben und jeweils 2.5 MByte Daten lesen. Ungefähr 75 Prozessoren werden gleichzeitig dieser Aufgabe zugeordnet. Die gesamte Aufgabe ist daher in etwa 12 Minuten vollständig gelöst, dazu mußte der Fileserver ingesamt 750 MByte Daten liefern. Diese Aufgabe benötigt daher allein bereits eine durchschnittliche Datenrate von ungefähr 1 MByte pro Sekunde.
Tatsächlich konzentrieren sich die Zugriffe aber auf den Start des Programms und lasten dabei den Server vollständig aus - 75 Prozesse versuchen gleichzeitig je 2,5 Mbyte aus dem Server zu laden. Unter günstigsten Voraussetzungen liefert der Server 11 MByte pro Sekunde, und es dauert daher mindestens 70 Sekunden bis alle Daten gelesen werden.
Bitte beobachten sie Ihre Programme, damit es nicht notwendig wird, Limits bei der Anzahl gleichzeitig verwendbarer Rechner einzuführen.

Obskure Fehlermeldung: Shadow exception!

Manchmal tritt die Fehlermeldung 

   Shadow exception!
   Can no longer talk to condor_starter on execute machine (129.27.xx.xx)

auf. Weil diese Fehlermeldung häufig mit einem Programmabsturz einhergeht wird verschiedentlich ein falscher Zusammenhang hergestellt -- diese Fehlermeldung ist nicht die Ursache, sondern Folge eines Programmabsturzes: Wenn Jobs sehr kurze Laufzeiten haben, können nicht alle auf einem Rechner laufenden Condor-Prozesse die notwendigen Initialisierungen abschließen, bevor dieser Prozess schon beendet ist.

Ich kann mit einer Serie von Testprogrammen unterschiedlicher Länge dieses Fehlermeldung bei sehr kurzen Prozessen provozieren, trotzdem sind alle Ergebnisse der Testroutinen korrekt. Weitere Hinweise auf ähnliches Verhalten finden sie auch in der Email Liste condor users.


Fehlersuche

Wenn Programme unter HTCondor abstürzen und keine korrekten oder vollständigen Ergebnisse produzieren, ist praktisch immer ihr Programm daran schuld. Bitte starten Sie ihre Programme dann auch direkt unter Verwendung exakt der selben Parameter und Eingabedaten; dazu kann es notwendig sein, auch den Seed der Zufallszahlengeneratoren einstellbar zu machen.

Matlab-Programme unter Condor

Wenn Matlab-Programme unter HTCondor laufen, sind vor allem die Anzahl der verfügbaren Lizenzen ein ernstes Hindernis. Wir verfügen am Institut nur über 10 garantierte Floating Lizenzen aus dem Pool der TU Graz. Daher müßen Matlab-Skripte unbedingt kompiliert werden.

Damit das erzeugte Binary dann unter HTCondor die Support-Libraries findet und reibungslos funktioniert, sind in der Submit-Datei einige Besonderheiten notwendig:

Hier ein kurzes Beispiel, wie man eine kompilierte Matlab-Funktion an Condor übergibt:

  • Unser ausführbares Programm heißt bh_disorder_mott_function und das dazugehörige Shell-Skript run_bh_disorder_mott_function.sh. Beides sollte vom Matlab-Compiler erstellt worden sein. Als Executable ist nun das Shell-Skript und nicht das eigentliche Matlab-Executable anzugeben, da sonst die Umgebungsvariablen nicht korrekt gesetzt werden. Außerdem muss Getenv = True gesetzt werden. Die environment-Variable müsste eigentlich nicht immer gesetzt werden, jedoch kann z.B. der Fehler Could not access the MCR component cache auftreten. In diesem Fall muss man dann den Ort für MCR_CACHE_ROOT per Hand festlegen.
  • Programme, die mit den Matlabversionen 2008 und aktueller kompiliert wurden brauchen bei den Requirements den Zusatz MatlabVersion == "R2010b", da die älteren Versionen für diese Funktionen nicht mehr kompatibel sind.
  • Ein sehr wichtiger Punkt ist, dass man transfer_files = always setzt. Das erste Argument von transfer_input_files muss nun die ausführbare Funktion von Matlab sein, also in unserem Fall bh_disorder_mott_function. Als weitere Argumente kann man weitere Dateien eingeben, die das Programm u.U. benötigt. (In unserem Fall z.B. mott_4_2.mat)
  • Als Input wird nun wieder die ausführbare Matlab-Datei angegeben, der Output ist beliebig, in unserem Fall werden einfach Textdateien out.0, out.1, ... erstellt, die das enthalten, was die Matlab-Funktion ausgibt, würde sie in Matlab ausgeführt werden. Die Befehle für die error- und log-files sind wie Output frei wählbar.
  • Zum Abschluss müssen unserem Programm noch Argumente übergeben werden wie bei einer "normalen" Matlab-Funktion. Zu beachten ist aber, dass das erste Argument immer der Matlab-Pfad sein muss, in unserem Fall also /afs/itp.tugraz.at/opt/matlab. Danach folgen die Funktionsparameter, wobei diese nicht mit einem Komma getrennt werden, sondern mit einem Leerzeichen.

Achtung: Die Matlab-Funktion erhält die eingegebenen Parameter im Ascii-Format. Man muss also in der Funktion vor dem Kompilieren eine Abfrage einbauen, die die Strings, falls nötig, in Zahlen umwandelt. Eine Möglichkeit ist z.B.: 

   if ischar(parameter) == 1
      parameter = str2double(parameter);   % bzw. str2num(parameter)
   end
  • Zum Schluss wird mit queue 1 der Prozess einmal eingereiht.
   ###################                    
   #
   # Bose-Hubbard with disorder, test
   # 
   ###################                                                    
   
   Universe   = vanilla 
   Executable = run_bh_disorder_mott_function.sh
   
   Getenv      = True
   environment = MCR_CACHE_ROOT=/temp/<username>/bh_disorder_mott_function/temp;MATLAB_PREFDIR=/temp/<username>/bh_disorder_mott_function/temp
   
   Requirements = MatlabVersion == "R2009b"
   
   transfer_files       = always
   transfer_input_files = bh_disorder_mott_function,mott_4_2.mat
   
   Input  = bh_disorder_mott_function
   Output = out.$(Process)

       
   error  = /temp/<username>/bh_disorder_mott_function/distrib/error
   log    = /temp/<username>/bh_disorder_mott_function/distrib/log
   
   
   Arguments = /afs/itp.tugraz.at/opt/matlab 4 4 50 100 10 0 10 1 1 2
   queue 1


Weblinks:

Alternativen

Einer der unerfreulichen Aspekte der Condor-Lizenz war die Unmöglichkeit, eigene Pakete aus den Sourcen zu erzeugen. Das führt zu Problemen mit installierten Bibliotheken und mangelhaft unterstützten Architekturen (z.B. amd64). Ab der Version 7.1.0 wurden die Sourcen unter der Apache-Lizenz frei verfügbar gemacht, allerdings ist es noch kompliziert und fehleranfällig Condor selbst zu kompilieren, weil das Build-System außergewöhnlich kompliziert und überfrachtet ist. Viele Teile sind außerdem mit modernen Compilern und Bibliotheken nur eingeschränkt kompatibel. Die Ergebnisse einses Versuchs, native Pakete für Debian Linux zu bauen, sind am Webserver des Instituts unter http://itp.tugraz.at/Comp/debian/dists/etch/main/binary-i386/ bzw. http://itp.tugraz.at/Comp/debian/dists/etch/main/source/ zu finden.

Einige mögliche Konkurrenzprodukte zu Condor sind:

Abgerufen von „https://itp.tugraz.at/wiki/index.php?title=HTCondor&oldid=8108“