Steffen über SQL Server und Business Intelligence

Steffen Krause - Microsoft Technical Evangelist

HPC, Fortran und Brandschutz Teil 3 - Der MPI Clusterdebugger

HPC, Fortran und Brandschutz Teil 3 - Der MPI Clusterdebugger

  • Comments 1
  • Likes

Einer der großen Vorteile, die sich hhpberlin von der Verwendung der Microsoft Entwicklungsplattform verspricht ist die Möglichkeit, parallel im Cluster zu debuggen. Für den Anfang soll dabei der in Visual Studio 2008 (und 2005) integrierte MPI Clusterdebugger verwendet werden. Später wird als Alternative das Visual Studio Plugin DDKLite von Allinea evaluiert.

Um den Visual Studio Debugger einzusetzen muss er zuerst ausgewählt werden. Und dabei habe ich eine Überraschung erlebt. Hier die Einstellungsseite eines Visual C++ Projekts, Debugging Tab:

image

Wie man sieht kann man einfach den MPI Clusterdebugger auswählen.

Jetzt dieselbe Seite für ein Intel Fortran Projekt wie FDS5:

image

Wie man sieht - keine Möglichkeit, den MPI Debugger auszuwählen.

Aber aber einen Trick gefunden: FDS5 verwendet eine statische C++-Library. Diese kompiliere ich mit dem Visual C++ Compiler (nicht Intel C++). Der Trick ist nun, diese Library statt des eigentlichen Executable-Projekts als Startobjekt festzulegen und alle Debuggingeinstellungen da zu machen. Dem Debugger ist es egal, aus welchem Projekt er gestartet wird.

Die nächste Aufgabe war es, geeignete Einstellungen für den Debugging-Dialog zu finden. Dazu muss der Debugger einen Job im HPC-Scheduler erzeugen. Der Scheduler verteilt die einzelnen Prozesse auf die Clusterknoten und der Debugger hängt sich an diese Prozesse an. Die alte Anweisung für Compute Cluster Server 2003 funktioniert mit HPC Server 2008 nicht mehr!

Stattdessen muss man den Debugger einen HPC Scheduler Job erzeugen lassen.

Hier die Konfiguration:

  • MPIRun Befehl: job
  • MPIRun Argumente: submit /workdir:<UNC-Pfad Arbeitsverzeichnis>  /requestednodes:<Nodeliste, Komma-getrennt> /scheduler:<Headnode-Name> /numcores:<Anzahl der gewünschten MPI-Prozesse> /stdout:<UNC-Pfad Out-Datei>  /stderr:<UNC-Pfad Err-Datei> mpiexec
  • MPIRun-Arbeitsverzeichnis: Leer
  • Anwendungsbefehl: UNC-Pfad zum Debug-Executable
  • Anwendungsargumente: Argumente für die Anwendung
  • MPIShim-Speicherort: Vollständiger Pfad zu MPIShim.exe, muss auf allen Knoten gültig sein
  • MPI-Netzwerksicherheitsmodus: Wie gewünscht

Durch diese Parameter wird ein Debug-Job im Cluster erzeugt.

Ehe nun das Debuggen losgehen kann sind einige Einstellungen auf den ausgewählten Knoten erforderlich.

  1. Auf allen Knoten muss der Visual Studio Remote Debugger aus C:\Program Files\Microsoft Visual Studio 9.0\Microsoft Visual Studio 2008 Remote Debugger - DEU installiert werden
  2. Der Remote Debugger muss auf allen Knoten konfiguriert und gestartet werden
  3. Da cmd.exe normalerweise Probleme mit UNC-Pfaden hat sollte auf dem Head Node und allen zum Debuggen verwendeten Compute Nodes im Registry im Pfad HKEY_CURRENT_USER\Software\Microsoft\Command Processor ein DWORD mit dem Namen DisableUNCCheck und dem Wert 1 erzeugt werden
  4. Das zum Debuggen verwendete Programm MPIShim benötigt die Visual C++ Laufzeitbibliotheken. Sind diese nicht vorhanden bekommt man einen Fehler "The application has failed to start because its side-by-side configuration is incorrect." Um die Libraries zu installieren habe ich einfach ein Setup-Projekt erzeugt, das nur das Merge Module Microsoft_VC90_CRT_x86_x64.msm enthält, daraus ein Installer-Paket gebaut und dieses auf den Debug-Knoten installiert.

Eine Einstellung, die von den persönlichen Präferenzen abhängt ist die Frage, ob der Debugger beim Anhalten im Breakpoint alle Prozesse unterbrechen soll oder nur den, der auf den Breakpoint gelaufen ist. Das kann man unter Extras-Optionen-Debugging-Allgemein einstellen:

image

Ist all das konfiguriert kann man Breakpoints setzen und dann einfach das Projekt starten. Der Debugger erzeugt den Job im Cluster und verbindet sich dann mit den einzelnen Prozessen:

image

Sinnvoll ist es dann, als erstes eine Überwachung auf den MPI Rank zu setzen (das ist die MPI-eigene ID des jeweiligen Prozesses), damit man in jedem Breakpoint sofort sieht in welchem Prozess man ist.

Nach dem Beenden des Debuggens darf man nicht vergessen, den Job im HPC Job Scheduler zu beenden, sonst bleiben die knoten blockiert und man kann weder noch einmal debuggen noch andere Rechnungen ausführen.

Wer übrigens wissen will, wie man den MPI Debugger lokal für mehrere Prozesse einsetzt: Das ist hier dokumentiert. Dabei dann die Teile zum Remote Debug Monitor ignorieren.

Gruß,
Steffen

Comments
  • Nach den drei Artikeln zu meinen konkreten Projekterfahrungen wird es nun langsam Zeit, dass ich ein

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment