Debuggen von Leistungsengpässen
Wenn Sie eine HPC-Anwendung (High-Performance Computing) auf einer großen Anzahl von VMs (mehr als 16) ausführen, ist es am besten, ein kleineres Problem auf weniger virtuellen Computern auszuführen. Dieser Test überprüft, ob Ihre HPC-Anwendung wie erwartet ausgeführt wird.
Wenn Sie eine parallele HPC-Anwendung auf mehr VMs (mit mehr parallelen Prozessen) ausführen, können Sie nicht einfach davon ausgehen, dass die tatsächliche Zeit (verstrichene Echtzeit) immer weiter abnimmt. Tatsächlich können viele eng gekoppelte HPC-Anwendungen eine längere tatsächliche Zeit aufweisen, wenn Sie versuchen, sie auf anderen VMs auszuführen.
Die längere tatsächliche Zeit kann verschiedene Gründe haben. Zum Beispiel:
Möglicherweise implementieren Sie einen parallelen Algorithmus ineffizient.
Die Problemgröße, also die Modellgröße oder die Anzahl der Freiheitsgrade (NDOF), ist nicht ausreichend. Wenn Ihre Anwendung in mehreren parallelen Prozessen ausgeführt wird, ist die Menge an Berechnungen pro Prozess zu klein. Daher dominiert die Kommunikationszeit zwischen den parallelen Prozessen die Gesamtwandzeit. Die Zunahme bei der Kommunikationszeit führt zu einer Erhöhung der gesamten tatsächlichen Zeit.
Es ist wichtig zu wissen, wie gut Ihre HPC-Anwendung skaliert werden kann, die die Problemgröße ausführt, an der Sie interessiert sind. Sie können dann bestimmen, welche parallel Effizienz im Hinblick auf Leistung und Kosten akzeptabel ist.
Mit der folgenden Formel für eine parallele Beschleunigung wird gemessen, wie stark sich die parallele Anwendungsleistung verbessert, wenn Sie weitere parallele Prozesse hinzufügen:
$${\text{Parallele Beschleunigung}} = {\dfrac{\text{Tatsächliche Zeit (1 Prozess)}}{\text{Tatsächliche Zeit (n Prozesse)}}}$$
Die folgende Formel für parallele Effizienz zeigt, wie effizient Sie die Berechnungsressourcen verwenden, wenn Sie weitere Prozesse hinzufügen, um die Leistung paralleler Anwendungen zu steigern:
$${\text{Parallele Effizienz}} = {\dfrac{\text{Parallele Beschleunigung}}{\text{N Prozesse}}}$$
Wenn Sie sich unsicher im Hinblick auf die parallele Leistungsskalierung für Ihre eng gekoppelte HPC-Anwendung sind, können Sie Skalierungstests durchführen. Anders formuliert: Führen Sie Ihre Anwendung mit 1, 2, 4, 8, 16 usw. parallelen Prozessen aus. Berechnen Sie die parallele Beschleunigung und die parallele Effizienz, und entscheiden Sie dann auf Grundlage dieser Ergebnisse, wie viele parallele Prozesse Sie verwenden möchten.
Deaktivieren Sie ggf. nicht erforderliche Dienste, die sich auf die parallele Skalierung auswirken könnten, z. B. den Azure Linux-Agent, bevor Sie Ihre Aufträge ausführen. Anschließend können Sie die Dienste nach Abschluss der Aufträge wieder aktivieren. Diese Empfehlung ist besonders dann zu beachten, wenn Sie alle verfügbaren Kerne verwenden und auf eine große Anzahl VMs hochskalieren.
Zum Beenden des Azure Linux-Agent verwenden Sie den folgenden Befehl:
sudo system stop waagent.service
Überprüfen der Leistung
In den nachfolgenden Abschnitten finden Sie Informationen zu grundlegenden Prüfungen, mit denen Sie mögliche Leistungsprobleme ermitteln können.
Überprüfen, ob die richtige Anzahl an Prozessen und Threads auf den einzelnen VMs ausgeführt wird
Eine einfache Möglichkeit zu bestimmen, ob Sie die richtige Anzahl an Prozessen und Threads auf den einzelnen VMs verwenden, ist das Abrufen des Durchschnittswerts für die Systemlast auf den einzelnen VMs. Dafür können Sie ein Tool wie uptime verwenden. Der Wert sollte in etwa identisch mit der erwarteten Gesamtanzahl an Prozessen und Threads auf den einzelnen VMs sein. Wenn der erfasste Lastdurchschnitt niedriger oder höher als die erwartete Gesamtanzahl an Prozessen und Threads ist, weist dies auf ein Problem hin, das behoben werden muss.
Sie sollten die Argumente für das Übergeben der Schnittstelle (MPI) und die Angabe der Anzahl paralleler Threads sorgfältig überprüfen. Überprüfen Sie beispielsweise die Befehlszeilenargumente Ihrer Anwendung oder die Werte von Umgebungsvariablen wie OMP_NUM_THREADS.
Überprüfen einer gleichmäßigen Verteilung der Prozesse und Threads auf allen NUMA-Knotendomänen
Wenn Sie das top- oder htop-Tool verwenden, können Sie die Domänenansicht des Nichtuniform-Speicherzugriffs (Nonuniform Memory Access, NUMA) auswählen, indem Sie 2 als Befehlszeilenparameter angeben. (Beispiel: Für HB120_v2 sollte angezeigt werden, dass 30 NUMA-Knotendomänen diese Ansicht nutzen.)
Der Prozentsatz der Benutzerauslastung sollte auf alle NUMA-Domänen gleichmäßig verteilt werden. Wenn dies nicht der Fall ist, überprüfen Sie die MPI-Befehlszeilenargumente und -Umgebungsvariablen.
Die folgende Abbildung zeigt die Ausgabe des Linux-Tools top in der NUMA-Ansicht. In diesem Fall ist jede NUMA-Domäne zu 50 Prozent ausgelastet.
Überprüfen des Ausführungsstatus von Prozessen und Threads
Zur Überprüfung des Ausführungsstatus Ihrer Prozesse und Threads sollten Sie top verwenden. Im Idealfall sollten alle Prozesse und Threads den Ausführungszustand (R) aufweisen.
Wenn sich einige oder alle Ihrer Prozesse und Threads in einem unterbrechungsfreien Ruhezustand (D) befinden oder in einem Ruhezustand (S), untersuchen Sie die Situation, um die Gründe zu verstehen. Je nachdem, wie der Algorithmus Ihrer Anwendung entworfen wurde, kann es sich beim Ruhezustand um ein normales und erwartetes Verhalten für Prozesse und Threads handeln. Es könnte aber auch auf eine Ressourceneinschränkung hinweisen, z. B. dass aufgrund der von Ihnen verwendeten Speicherlösung die E/A-Leistung nicht ausreichend ist.
Die folgende Formel zeigt, wie effizient Ihrer parallele Anwendung ausgeführt wird, wenn sie auf einige Systemressourcen wartet (z. B. E/A), und es werden Informationen zum Umfang angezeigt:
$${\text{Wartezeit für die Anwendung}} = {\text{Tatsächliche Zeit}} - \left( {\dfrac{\text{Totale CPU-Zeit für alle parallelen Prozesse}}{\text{Anzahl paralleler Prozesse}}} \right)$$
Überprüfen, ob die Anwendung E/A-gebunden ist
Prozesse und Threads, die sich für einen erheblichen Zeitraum in einem unterbrechungsfreien Ruhezustand (D) oder einem Ruhezustand (S) befinden, können ein Indikator dafür sein, dass ein E/A-Engpass besteht, der untersucht werden muss. Einige HPC-Anwendungen bietet eine Leistungsprofilerstellung als Teil ihrer Ausgabe. Diese Profile zeigen den prozentualen Zeitanteil, während dem E/A-Vorgänge durchgeführt werden, sowie E/A-Raten für Lese- und Schreibvorgänge, die ebenfalls auf einen E/A-Engpass hinweisen können.
Wenn Sie sich unsicher sind, in welche Richtung sich die E/A-Leistung bewegt, können Sie Tools wie iostat als Unterstützung verwenden. Um zu überprüfen, ob sie ein E/A-Problem haben, ändern Sie Ihre Speicherlösung in etwas, von dem Sie wissen, dass es schneller ist als das, was Sie verwenden. Dann führen Sie Ihre HPC-Anwendung erneut aus. Sie können z. B. eine schnelle lokale NVMe-SSD oder RAM-Disk verwenden.
Nachdem Sie diese Änderung vorgenommen haben, stellen Sie sich die folgenden Fragen: Sehen Sie eine Verbesserung der E/A-Zeit? Hat sich die tatsächliche Zeit insgesamt verbessert? Wenn ja, wie viel ist akzeptabel?
Überprüfen, ob die Anwendung netzwerkgebunden ist
Ermitteln Sie den prozentualen Anteil der gesamten tatsächlichen Zeit, den Ihre Anwendung für das Durchführen der Prozesskommunikation aufwendet. (In der Regel handelt es sich dabei um MPI-Kommunikation.)
Wenn Ihre Anwendung netzwerkgebunden ist, vergewissern Sie sich, dass Sie beim Ausführen Ihrer HPC-Anwendung das InfiniBand-Netzwerk verwenden. Wenn eine hybride Parallelversion verfügbar ist, stellen Sie fest, ob dadurch die Kommunikationszeit im Netzwerk gesenkt werden kann.
Wenn Sie Zugriff auf den Quellcode haben, überprüfen Sie, ob es effizientere Möglichkeiten gibt, die Kommunikation zu implementieren. Verwenden Sie beispielsweise kollektive Vorgänge anstelle von Punkt-zu-Punkt-Vorgängen, oder versuchen Sie, asynchrone Kommunikation anstelle synchroner Kommunikation zu nutzen.