Fehlerbehebung bei GPU-VMs

Auf dieser Seite wird beschrieben, wie Sie Probleme mit VMs beheben, die auf Compute Engine ausgeführt werden und an die GPUs angehängt sind.

Wenn Sie versuchen, eine VM mit angehängten GPUs zu erstellen und Fehler erhalten, dann lesen Sie die Informationen unter Fehlerbehebung bei Fehlern zur Ressourcenverfügbarkeit und Fehlerbehebung bei der Erstellung und Aktualisierung von VMs.

Fehlerbehebung bei GPU-VMs mit NVIDIA DCGM

NVIDIA Data Center GPU Manager (DCGM) ist eine Suite von Tools zum Verwalten und Überwachen von NVIDIA-GPUs in Rechenzentren in Clusterumgebungen.

Wenn Sie DCGM zur Fehlerbehebung in Ihrer GPU-Umgebung verwenden möchten, gehen Sie so vor:

• Verwenden Sie den neuesten empfohlenen NVIDIA-Treiber für das GPU-Modell, das an Ihre VM angehängt ist. Informationen zu Treiberversionen finden Sie unter Empfohlene NVIDIA-Treiberversionen.
• Achten Sie darauf, dass Sie die neueste Version von DCGM installiert haben. Informationen zum Installieren der neuesten Version finden Sie unter DCGM-Installation.

Probleme diagnostizieren

Wenn Sie einen dcgmi-Diagnosebefehl ausführen, enthalten die vom Diagnosetool gemeldeten Probleme die nächsten Schritte zur Behebung des Problems. Das folgende Beispiel zeigt die umsetzbare Ausgabe des Befehls dcgmi diag -r memory -j.

{
  ........
   "category":"Hardware",
   "tests":[
      {
         "name":"GPU Memory",
         "results":[
            {
               "gpu_id":"0",
               "info":"GPU 0 Allocated 23376170169
bytes (98.3%)",
               "status":"Fail",
               ""warnings":[
                  {
                     "warning":"Pending page
retirements together with a DBE were detected on GPU 0. Drain the GPU and reset it or reboot the node to resolve this issue.",
                     "error_id":83,
                     "error_category":10,
                     "error_severity":6
                  }
               ]
            }
  .........

Aus dem vorherigen Ausgabeschnipsel geht hervor, dass für GPU 0 ausstehende Seitendeaktivierungen vorliegen, die durch einen nicht behebaren Fehler verursacht werden. Die Ausgabe enthält die eindeutige error_id und Tipps zur Fehlerbehebung. Für diese Beispielausgabe wird empfohlen, die GPU zu leeren und die VM neu zu starten. In den meisten Fällen können Sie das Problem beheben, indem Sie der Anleitung in diesem Abschnitt der Ausgabe folgen.

Profi-Tipp:Notieren Sie sich den Schweregrad des Fehlers. In der Beispielausgabe entspricht ein Wert von "error_severity":6 einem DCGM_ERROR_RESET. Das bedeutet, dass ein Zurücksetzen Probleme mit diesem Schweregradwert behebt.

Eine vollständige Liste der error_severity Werte finden Sie im dcgmErrorSeverity_enum Abschnitt in der dcgm_errors GitHub-Datei.

Fehlerbehebung bei GPU-Leistungsproblemen für A3-VMs

Die A3-Maschinenserie ist mit angehängten NVIDIA H200- oder H100-GPUs verfügbar. Diese Serie umfasst die Maschinentypen A3 Ultra (H200), A3 Mega (H100), A3 High (H100), und A3 Edge (H100).

Fehlerhaften Knoten identifizieren

Umfangreiche Trainings- oder Benchmarkjobs in einem GPU-Cluster mit mehreren Knoten reagieren möglicherweise nicht mehr oder haben eine schlechte Leistung. Das liegt oft daran, dass ein oder mehrere Knoten eine schlechte Leistung erbringen und den gesamten Vorgang verlangsamen. In diesem Abschnitt wird beschrieben, wie Sie einen fehlerhaften Knoten oder einen fehlerhaften Hostcomputer identifizieren, indem Sie entweder einen NCCL-Benchmarktest ausführen oder NCCL-Logs analysieren.

NCCL-Benchmarktest ausführen

Um die Gruppe von Knoten zu identifizieren, die den Fehler verursachen, testen Sie systematisch Teilmengen Ihres Clusters mit NCCL-Benchmarks wie all_reduce_perf.

1. Um Ihre Knotensätze zu identifizieren, gruppieren Sie Ihre Knoten in logische Sätze, z. B. Partitionen in Slurm.
2. Erstellen Sie Hostdateien, indem Sie für jeden Knotensatz eine separate Hostdatei erstellen, in der Hostnamen und die Anzahl der GPUs pro Knoten aufgeführt sind. Die Anzahl der von Ihnen angegebenen Slots hängt von der GPU-Anzahl Ihres A3-VM-Typs ab. Beispielsweise haben a3-highgpu-8g VMs 8 GPUs. Daher müssen Sie slots=8 angeben.
3. Führen Sie zum Ausführen von Benchmarks den all_reduce_perf Benchmark für jeden Knotensatz einzeln aus.

   mpirun -x LD_LIBRARY_PATH --hostfile HOSTFILE_NAME -n TOTAL_PROCESSES \
       ./build/all_reduce_perf -b 1G -e 8G -f 2 -g NUM_GPUS_PER_NODE
             

   Ersetzen Sie Folgendes:

   • HOSTFILE_NAME: Der Name der Hostdatei, die die Liste der Knoten und die Anzahl der GPUs pro Knoten für den Knotensatz enthält.
   • TOTAL_PROCESSES: Die Gesamtzahl der MPI-Prozesse, die auf allen Hosts im Knotensatz gestartet werden sollen.
   • NUM_GPUS_PER_NODE: Die Anzahl der GPUs pro Knoten. Für alle A3-Maschinentypen ist dieser Wert 8.
4. Wenn ein Job für einen bestimmten Knotensatz hängt oder eine deutlich niedrigere Bus bandbreite (busbw) aufweist, ist dieser Satz wahrscheinlich fehlerhaft.
5. Wenn ein Knotensatz fehlerhaft ist, teilen Sie seine Hostdatei in zwei Hälften und führen Sie den Test noch einmal aus, um die binäre Suche einzugrenzen, bis Sie den einzelnen fehlerhaften Knoten gefunden haben.

NCCL-Logs analysieren

Wenn mit der Benchmarkmethode kein Knoten identifiziert wird, analysieren Sie detaillierte NCCL-Logs.

1. Setzen Sie die folgenden Umgebungsvariablen in der Shell-Sitzung, in der Sie Ihre Arbeitslast ausführen möchten, um das Debug-Logging zu aktivieren:

   export NCCL_DEBUG=INFO
           export NCCL_DEBUG_SUBSYS=INIT,NET,COLL
           export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"
           

   Ersetzen Sie LOG_DIRECTORY durch das Verzeichnis, in dem Sie Ihre Logs speichern möchten.

   Wenn Sie NCCL_DEBUG_FILE mit %h und %p festlegen, werden für jeden Prozess eindeutige, nicht verschachtelte Logdateien erstellt.

   Wenn Sie eine Arbeitslast mit mehreren Knoten mit mpirun ausführen, müssen Sie diese Variablen mit dem Flag -x an alle Knoten weitergeben. Beispiel:

   mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ...
             

2. Verwenden Sie den folgenden Befehl, um den ersten Fehler zu finden. Damit werden die frühesten Zeitüberschreitungs- oder Fehlerereignisse in allen Logdateien gesucht:

   grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \
     | sort | head -n 20
             

   Ersetzen Sie LOG_DIRECTORY durch das Verzeichnis, in dem Ihre Logs gespeichert sind.

3. Um kollektive Vorgänge zu zählen, führt ein Nachzüglerknoten weniger kollektive Vorgänge aus. Zählen Sie die Einträge "opCount" für verdächtige Ränge:

   grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -l
             

   Ersetzen Sie Folgendes:

   • LOG_DIRECTORY: Das Verzeichnis, in dem Ihre Logs gespeichert sind.
   • HOSTNAME: Der Hostname des Knotens.
   • PID: Die Prozess-ID des NCCL-Prozesses.
4. Erhöhen Sie vorübergehend das Zeitlimit für die Datenübertragung, um mehr Logging-Daten zu erfassen, bevor ein Job abgebrochen wird:

   export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
           

Thermische Drosselung der GPU überwachen

Bei VMs der A3-Serie kann es zu Leistungseinbußen kommen, wenn sie unter Last konstant Temperaturen über 87 °C erreichen. Verwenden Sie nvidia-smi oder dcgmi, um die thermische Drosselung der GPU auf allen Knoten in einem Cluster zu prüfen.

„nvidia-smi“ verwenden

Führen Sie den folgenden Befehl aus, um die aktuelle Temperatur und den Drosselungsstatus aller GPUs auf einem Knoten zu prüfen:

nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv
    

In der Ausgabe gibt ein Wert von Active in der clocks_throttle_reasons.hw_slowdown Spalte an, dass die GPU aufgrund hoher Temperaturen gedrosselt wird.

„dcgmi“ verwenden

Die NVIDIA Data Center GPU Manager (DCGM)-Diagnosesuite enthält Prüfungen auf thermische Verstöße. Führen Sie den folgenden Befehl aus, um eine Diagnose der Stufe 1 auszuführen:

dcgmi diag -r 1

Ein Ergebnis von Warn oder Fail im Abschnitt Thermal gibt an, dass während des Tests ein thermischer Verstoß aufgetreten ist. Wenn ein thermischer Verstoß mit Taktfrequenzdrosselung einhergeht, überhitzt die GPU wahrscheinlich und muss weiter untersucht werden.

Supportfall eröffnen

Wenn Sie die Probleme mit der Anleitung auf dieser Seite nicht beheben können, erfassen Sie die folgenden Informationen und eröffnen Sie einen Supportfall:

• Projekt-ID und eine Liste aller Instanznamen oder ‑IDs im Cluster.
• Liste der verdächtigen Knoten , die bei der Fehlerbehebung identifiziert wurden.
• Vollständige, nicht verschachtelte NCCL-Logs mit aktivierten Debug-Einstellungen.
• Ausgabe von Hardware-Systemdiagnosen (dcgmi, nvidia-smi).
• Genaue Benchmark- oder Arbeitslastbefehle , die fehlschlagen.
• Relevante Logdateien , z. B. Host-Engine- und Diagnoseprotokolle. Führen Sie dazu gather-dcgm-logs.sh aus, das sich in Standardinstallationen unter /usr/local/dcgm/scripts befindet.
• NVIDIA-Fehlerbericht. Führen Sie nvidia-bug-report.sh aus. Folgen Sie für Blackwell-GPUs der Anleitung unter NVIDIA-Fehlerbericht für Blackwell-GPUs erstellen.
• Details zu allen kürzlich vorgenommenen Änderungen an Ihrer Umgebung, die dem Fehler vorausgingen.

Xid-Meldungen prüfen

Nachdem Sie eine VM mit angehängten GPUs erstellt haben, müssen Sie NVIDIA-Gerätetreiber auf Ihren GPU-VMs installieren, damit Ihre Anwendungen auf die GPUs zugreifen können. Manchmal geben diese Treiber jedoch Fehlermeldungen zurück.

Eine Xid-Meldung ist ein Fehlerbericht des NVIDIA-Treibers, der in das Kernel-Log oder Ereignisprotokoll des Betriebssystems für Ihre Linux-VM geschrieben wird. Diese Meldungen werden in der Datei /var/log/messages platziert.

Weitere Informationen zu Xid-Meldungen, einschließlich möglicher Ursachen, finden Sie in der NVIDIA-Dokumentation.

Der folgende Abschnitt enthält Anleitungen zum Umgang mit einigen Xid-Nachrichten, die nach den häufigsten Typen gruppiert sind: GPU-Arbeitsspeicherfehler, GPU-Systemprozessor-Fehler und Fehler bezüglich ungültigen Arbeits-Speicherzugriff.

GPU-Arbeitsspeicherfehler

GPU-Arbeitsspeicher ist der Speicher, der auf einem GPU-Gerät verfügbar ist und zum temporären Speichern von Daten verwendet werden kann. Der GPU-Arbeits-Speicher ist durch den Fehlerkorrekturcode ECC geschützt, der Single-Bit-Fehler (SBE) erkennt und korrigiert und Double-Bit-Fehler (DBE) erkennt und meldet.

Vor der Veröffentlichung der NVIDIA A100-GPUs wurde die dynamische Seitendeaktivierung unterstützt. Für NVIDIA A100- und neuere GPU-Releases (z. B. NVIDIA H100) wird die Wiederherstellung nach Zeilenneuzuordnungsfehlern eingeführt. ECC ist standardmäßig aktiviert. Google empfiehlt dringend, ECC aktiviert zu lassen.

Im Folgenden sind einige häufige GPU-Arbeits-Speicherfehler und ihre empfohlenen Lösungen aufgeführt.

Xid-Fehlermeldung	Lösung
Xid 48: Double Bit ECC	Beenden Sie Ihre Arbeitslasten. Löschen Sie die VM und erstellen Sie sie neu. Wenn der Fehler weiterhin auftritt, senden Sie eine Supportanfrage an den Cloud Customer Care.
Xid 63: ECC page retirement or row remapping recording event	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück.
Xid 64: ECC page retirement or row remapper recording failure Die Meldung enthält die folgenden Informationen: Xid 64: All reserved rows for bank are remapped	Beenden Sie Ihre Arbeitslasten. Löschen Sie die VM und erstellen Sie sie neu. Wenn der Fehler weiterhin auftritt, senden Sie eine Supportanfrage an den Cloud Customer Care.
Wenn Sie mindestens zwei der folgenden Xid-Meldungen zusammen erhalten: Xid 48 Xid 63 Xid 64 Die Meldung enthält die folgenden Informationen: Xid XX: row remap pending	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück. Wenn Sie die GPU zurücksetzen, können die Zeilen-Neuzuordnung und Seitendeaktivierung abgeschlossen und die GPU repariert werden.
Xid 92: High single-bit ECC error rate	Diese Xid-Meldung wird zurückgegeben, nachdem der GPU-Treiber einen korrigierbaren Fehler behoben hat. Sie sollte sich nicht auf Ihre Arbeitslasten auswirken. Diese Xid Meldung dient nur zu Informationszwecken. Sie müssen nichts tun.
Xid 94: Contained ECC error	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück.
Xid 95: Uncontained ECC error	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück.

Fehler im GSP

Ein GPU-Systemprozessor (GSP) ist ein Mikrocontroller, der auf GPUs ausgeführt wird und einige der Hardwareverwaltungsfunktionen auf niedriger Ebene übernimmt.

Xid-Fehlermeldung	Lösung
Xid 119: GSP RPC timeout	Beenden Sie Ihre Arbeitslasten. Löschen Sie die VM und erstellen Sie sie neu. Wenn der Fehler weiterhin auftritt, erfassen Sie den NVIDIA-Fehlerbericht und senden Sie eine Supportanfrage an den Cloud Customer Care.
Xid 120: GSP error

Ungültiger Arbeitsspeicherzugriff-Fehler

Die folgenden Xids werden zurückgegeben, wenn Anwendungen illegale Arbeits-Speicherzugriffsprobleme haben:

• Xid 13: Graphics Engine Exception
• Xid 31: GPU memory page fault

Ungültiger Arbeits-Speicherzugriff-Fehler werden normalerweise dadurch verursacht, dass Arbeitslasten versuchen, auf Arbeitsspeicher zuzugreifen, der bereits freigegeben wurde oder außerhalb des zulässigen Bereichs liegt. Dies kann durch Probleme wie die Dereferenzierung eines ungültigen Zeigers oder durch ein Array außerhalb des gültigen Bereichs verursacht werden.

Um dieses Problem zu beheben, müssen Sie Ihre Anwendung debuggen. Dazu können Sie cuda-memcheck und CUDA-GDB verwenden.

In einigen sehr seltenen Fällen kann ein Hardwareverschlechterung dazu führen, dass Fehler zu ungültigem Arbeits-Speicherzugriff zurückgegeben werden. Verwenden Sie NVIDIA Data Center GPU Manager (DCGM), um festzustellen, ob das Problem mit Ihrer Hardware zusammenhängt. Sie können dcgmi diag -r 3 oder dcgmi diag -r 4 ausführen, um verschiedene Level an Testabdeckung und ‑dauer auszuführen. Wenn Sie feststellen, dass das Problem mit der Hardware zusammenhängt, senden Sie eine Supportanfrage an den Cloud Customer Care.

Weitere häufige Xid-Fehlermeldungen

Xid-Fehlermeldung	Lösung
Xid 74: NVLINK error	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück.
Xid 79: GPU has fallen off the bus Das bedeutet, dass der Treiber nicht mit der GPU kommunizieren kann.	Starten Sie die VM neu.
Xid 149 mit der Erwähnung von 0x02a, wie im folgenden Beispiel: Xid (PCI:0000:c0:00): 149,NETIR_LINK_EVT Fatal XC0 i0 Link 04 (0x02a485c6 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000) Dies weist auf ein bekanntes Problem hin, das die Firmware für NVIDIA B200-GPUs betrifft.	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück.

GPUs zurücksetzen

Bei einigen Problemen müssen Sie möglicherweise Ihre GPUs zurücksetzen. Führen Sie dazu die folgenden Schritte aus:

• Starten Sie für N1-, G2- und A2-VMs, die VM neu.
• Löschen Sie für G4-VMs, an die weniger als eine GPU angehängt ist, die VM und erstellen Sie sie neu.
• Führen Sie für A3- und A4-VMs sudo nvidia-smi --gpu-reset aus.
  • Bei den meisten Linux-VMs befindet sich die ausführbare Datei nvidia-smi im Verzeichnis /var/lib/nvidia/bin.
  • Bei GKE-Knoten befindet sich die ausführbare Datei nvidia-smi im Verzeichnis /home/kubernetes/bin/nvidia.
  • Wenn Sie GKE-Knoten verwenden, können Sie mit dem Tool „gpu-reset-tool“ das Zurücksetzen aller GPUs auf einem Knoten automatisieren. Für dieses Tool müssen Sie nur den Namen des Zielknotens angeben.

Alternativ werden GPUs auch zurückgesetzt, wenn Sie eine VM zurücksetzen oder neu starten.

Wenn die Fehler nach dem Zurücksetzen der GPU weiterhin auftreten, müssen Sie die VM löschen und neu erstellen.

Wenn der Fehler nach einem Löschen und Neuerstellen weiterhin besteht, senden Sie eine Supportanfrage an den Cloud Customer Care, um die VM in die Reparaturphase zu verschieben.

Nächste Schritte

Informationen zu GPU-Maschinentypen