Fehlerbehebung bei GPU-VMs

In diesem Leitfaden wird beschrieben, wie Sie häufige Probleme mit Compute Engine-VMs mit angehängten GPUs diagnostizieren und beheben, einschließlich Hardwarefehler und Leistungsengpässe.

Fehlerbehebung bei GPU-VMs mit NVIDIA DCGM

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

Wenn Sie DCGM zur Fehlerbehebung in Ihrer GPU-Umgebung verwenden möchten, führen Sie die folgenden Schritte aus:

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

Probleme diagnostizieren

Wenn Sie einen dcgmi-Diagnosebefehl ausführen, enthält die Ausgabe des Diagnosetools die nächsten Schritte, die Sie unternehmen können, um das Problem zu beheben. 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
                  }
               ]
            }
  .........

Im obigen Auszug sehen Sie, dass für GPU 0 aus einem nicht behebaren Fehler resultierende Seitenstilllegungen ausstehen. Die Ausgabe enthält die eindeutige error_id und Tipps zur Fehlerbehebung. Für diese Beispielausgabe wird empfohlen, die GPU zu entladen und die VM neu zu starten. In den meisten Fällen kann das Problem behoben werden, wenn Sie der Anleitung in diesem Abschnitt der Ausgabe folgen.

Probleme mit der GPU-Leistung bei A3-VMs beheben

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

Bei umfangreichen Trainings- oder Benchmark-Jobs in einem GPU-Cluster mit mehreren Knoten kann es vorkommen, dass das System nicht mehr reagiert oder die Leistung schlecht ist. Das liegt oft daran, dass ein oder mehrere Knoten nicht die erwartete Leistung erbringen und den gesamten Vorgang verlangsamen. In diesem Abschnitt wird beschrieben, wie Sie einen fehlerhaften Knoten oder Hostcomputer identifizieren, indem Sie entweder einen NCCL-Benchmarktest ausführen oder NCCL-Logs analysieren.

NCCL-Benchmark-Test ausführen

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

  1. Um Ihre Knotensets zu identifizieren, gruppieren Sie Ihre Knoten in logischen Sets, z. B. Partitionen in Slurm.
  2. Erstellen Sie für jeden Knotensatz eine separate Hostdatei mit Hostnamen und der Anzahl der GPUs pro Knoten. Die Anzahl der Slots, die Sie angeben, hängt von der Anzahl der GPUs Ihres A3-VM-Typs ab. a3-highgpu-8g-VMs haben beispielsweise 8 GPUs. Sie müssen also slots=8 angeben.
  3. Führen Sie zum Ausführen von Benchmarks die all_reduce_perf-Benchmark für jeden Knoten 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 das Nodeset enthält.
    • TOTAL_PROCESSES: Die Gesamtzahl der MPI-Prozesse, die auf allen Hosts im Nodeset gestartet werden sollen.
    • NUM_GPUS_PER_NODE ist die Anzahl der GPUs pro Knoten. Für alle A3-Maschinentypen ist dieser Wert 8.
  4. Wenn ein Job hängt oder die Busbandbreite (busbw) auf einem bestimmten Knotensatz deutlich niedriger ist, ist dieser Satz wahrscheinlich fehlerhaft.
  5. Wenn ein Knotensatz fehlerhaft ist, teilen Sie die zugehörige 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 die Benchmark-Methode keinen Knoten identifiziert, analysieren Sie detaillierte NCCL-Logs.

  1. Wenn Sie das Debug-Logging aktivieren möchten, legen Sie die folgenden Umgebungsvariablen in der Shell-Sitzung fest, in der Sie Ihre Arbeitslast ausführen möchten:
    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. Bei der Zählung kollektiver Vorgänge führt ein Straggler-Knoten weniger kollektive Vorgänge aus. Anzahl der Einträge für verdächtige Ränge: "opCount"
    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. Wenn Sie mehr Protokolldaten erfassen möchten, bevor ein Job abgebrochen wird, erhöhen Sie das Zeitlimit für die Datenübertragung vorübergehend:
    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 dauerhaft Temperaturen über 87 °C erreichen. Wenn Sie prüfen möchten, ob es auf den Knoten eines Clusters zu einer thermischen Drosselung der GPU kommt, verwenden Sie entweder nvidia-smi oder dcgmi.

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 Spalte clocks_throttle_reasons.hw_slowdown an, dass die GPU aufgrund hoher Temperaturen gedrosselt wird.

dcgmi verwenden

Die NVIDIA Data Center GPU Manager (DCGM) Diagnostic Suite enthält Prüfungen auf thermische Überschreitungen. 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 weist darauf hin, dass während des Tests ein thermischer Verstoß aufgetreten ist. Wenn ein thermischer Verstoß mit einer Taktfrequenzdrosselung einhergeht, überhitzt die GPU wahrscheinlich und muss weiter untersucht werden.

Supportfall eröffnen

Wenn Sie die Probleme mit den Informationen auf dieser Seite nicht beheben können, sammeln Sie die folgenden Informationen und erstellen Sie eine Supportanfrage:

  • Projekt-ID und eine Liste aller Instanznamen oder ‑IDs im Cluster.
  • Liste der verdächtigen Knoten, die durch die Fehlerbehebung ermittelt 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 wie Host-Engine- und Diagnoselogs. Führen Sie gather-dcgm-logs.sh aus, um diese Informationen zu erfassen. Die Datei befindet sich in Standardinstallationen unter /usr/local/dcgm/scripts.
  • NVIDIA-Fehlerbericht. Führen Sie nvidia-bug-report.sh aus. Für Blackwell-GPUs folgen Sie der Anleitung unter NVIDIA-Fehlerbericht für Blackwell-GPUs erstellen.
  • Details zu allen Änderungen, die vor dem Fehler in Ihrer Umgebung vorgenommen wurden.

Xid-Mitteilungen 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- oder Ereignisprotokoll des Betriebssystems Ihrer Linux-VM geschrieben wird. Diese Nachrichten 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
  1. Beenden Sie Ihre Arbeitslasten.
  2. 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
  1. Beenden Sie Ihre Arbeitslasten.
  2. Setzen Sie die GPUs zurück.
Xid 64: ECC page retirement or row remapper recording failure

Die Nachricht enthält die folgenden Informationen:

Xid 64: All reserved rows for bank are remapped
  1. Beenden Sie Ihre Arbeitslasten.
  2. 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 Nachricht enthält die folgenden Informationen:

Xid XX: row remap pending
  1. Beenden Sie Ihre Arbeitslasten.
  2. 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 behebaren Fehler korrigiert 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
  1. Beenden Sie Ihre Arbeitslasten.
  2. Setzen Sie die GPUs zurück.
Xid 95: Uncontained ECC error
  1. Beenden Sie Ihre Arbeitslasten.
  2. Setzen Sie die GPUs zurück.

Fehler im GSP

Ein GPU-Systemprozessor (GPU System Processor, 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
  1. Beenden Sie Ihre Arbeitslasten.
  2. Löschen Sie die VM und erstellen Sie sie neu. Wenn der Fehler weiterhin auftritt, erstellen Sie einen 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. Zum Debuggen Ihrer Anwendung 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. Wenn Sie feststellen möchten, ob das Problem an Ihrer Hardware liegt, verwenden Sie NVIDIA Data Center GPU Manager (DCGM). 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 an der Hardware liegt, erstellen Sie einen Fall bei Cloud Customer Care.

Weitere häufige Xid-Fehlermeldungen

Xid-Fehlermeldung Lösung
Xid 74: NVLINK error
  1. Beenden Sie Ihre Arbeitslasten.
  2. 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, in dem 0x02a erwähnt wird, 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 deutet auf ein bekanntes Problem mit der Firmware für NVIDIA B200-GPUs hin.

  1. Beenden Sie Ihre Arbeitslasten.
  2. Setzen Sie die GPUs zurück.

GPUs zurücksetzen

Bei einigen Problemen müssen Sie möglicherweise Ihre GPUs zurücksetzen. So setzen Sie GPUs zurück:

  • Starten Sie die VM neu.
  • Bei G4-VMs, an die weniger als eine GPU angehängt ist, müssen Sie die VM löschen und neu erstellen.
  • 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 das gpu-reset-tool verwenden, um das Zurücksetzen aller GPUs auf einem Knoten zu 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 eine VM neu starten.

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

Wenn der Fehler nach dem 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

GPUMaschinentypen ansehen