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.

So beheben Sie Probleme in Ihrer GPU-Umgebung mit DCGM:

• 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 zum Installieren der aktuellen Version finden Sie unter DCGM-Installation.

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 vorherigen Auszug sehen Sie, dass für GPU 0 ausstehende Seitenentfernungen aufgrund eines nicht behebaren Fehlers vorliegen. Die Ausgabe enthält die eindeutige error_id und Tipps zur Fehlerbehebung. Für diese Beispielausgabe empfehlen wir, die GPU zu entleeren 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.

Profitipp:Achten Sie auf den Schweregrad des Fehlers. In der Beispielausgabe entspricht ein Wert von "error_severity":6 einem DCGM_ERROR_RESET. Das bedeutet, dass Probleme mit diesem Schweregrad durch Zurücksetzen behoben werden.

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

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-Benchmarktest ausführen

Um die Gruppe von Knoten zu ermitteln, 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) in 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, übertragen Sie diese Variablen mit dem Flag -x auf alle Knoten. 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
           

GPU-Drosselung aufgrund von Überhitzung überwachen

Bei VMs der A3-Serie kann es zu Leistungseinbußen kommen, wenn sie unter Last dauerhaft Temperaturen über 87 °C erreichen. Verwenden Sie nvidia-smi oder dcgmi, um die thermische Drosselung der GPU auf den Knoten eines Clusters 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 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.

Xid-Fehler

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.

So geht Google mit Xid-Fehlern um

Google verwendet passive Systemdiagnosen, um GPU-Systeme zu bewerten. Wenn ein Hardwareaustausch erforderlich ist, leitet Google automatisch eine Notfallwartung ein. Google erkennt Xid-Fehler und sendet Geräte proaktiv zur Reparatur, wenn Fehlercodes wie Xid 74, 79 und 140 auf einen Hardwarefehler hinweisen. Einige Xid-Codes können durch Software- oder Hardwareprobleme verursacht werden. Google verwendet daher Mustervergleich, um Reparaturen auszulösen. Nicht jedes Auftreten führt also zu einer automatischen Reparatur.

Wichtig :Die von nvidia-smi gemeldeten aggregierten Fehlerzähler Aggregate SRAM Uncorrectable Parity stellen die Anzahl der Fehler über die gesamte Lebensdauer der GPU dar und werden weder beim Zurücksetzen der GPU noch beim Neustart der Instanz zurückgesetzt. Es ist normal, dass GPUs im Laufe ihrer Lebensdauer eine geringe Anzahl von Fehlern aufweisen. Google leitet automatisch Reparaturen ein, wenn die GPU aufgrund der Fehleranzahl über die gesamte Lebensdauer physisch repariert oder ausgetauscht werden muss.

Arten von Xid-Fehlern

In der folgenden Liste werden die drei Hauptkategorien von Xid-Fehlern und die empfohlenen Maßnahmen zur Fehlerbehebung beschrieben:

• Anwendungsfehler:Diese weisen auf Probleme in Ihrem Anwendungscode hin. Zu Anwendungsfehlern gehören XIDs wie 13, 31, 94, 95 und 137, die auf verschiedene Arten von Speicherzugriffsverletzungen hinweisen, ähnlich wie bei einem Segmentierungsfehler. Diese weisen nicht auf einen ECC-Fehler hin. Zur Behebung dieser Fehler empfiehlt NVIDIA einen der folgenden Debugging-Ansätze:

  • Direktes Debugging:Führen Sie die Anwendung direkt in cuda-gdb aus oder führen Sie das Compute Sanitizer-Tool „memcheck“ aus.
  • Debugging nach Ausnahme: Führen Sie die Anwendung mit CUDA_DEVICE_WAITS_ON_EXCEPTION=1 aus. Wenn eine Ausnahme auftritt, friert der GPU-Treiber den Anwendungsstatus ein, ohne die Anwendung zu beenden. So können Sie später einen Debugger (cuda-gdb -p <PID>) anhängen, um den Live-Stacktrace zu prüfen.

• Treiberfehler:Diese weisen auf Probleme hin, die durch den NVIDIA-GPU-Treiber verursacht werden. Um diese Fehler zu beheben, müssen Sie die neueste NVIDIA-Treiberversion verwenden. Google überwacht diese Fehler und arbeitet mit NVIDIA an der Behebung von Treiberproblemen.

• Durch Firmware oder Hardware behebbare Fehler:Diese Fehler weisen auf Firmware- oder Hardwarefehler hin, die ohne Hardwareaustausch behoben werden können. Um diese Fehler zu beheben, müssen Sie manuelle Wiederherstellungsmaßnahmen ergreifen, z. B. die GPU zurücksetzen oder die Instanz neu starten. Zu den durch Firmware oder Hardware behebbaren Fehlern gehören ECC-Fehler (Error Correcting Code, Fehlerkorrekturcode) (gilt für XIDs wie XID 48, 63 und 64), die verschiedene Phasen der Erkennung und Behebung von ECC-Fehlern angeben. Weitere Informationen zur Außerbetriebnahme von Seiten und zur Behebung von ECC-Fehlern finden Sie in den häufig gestellten Fragen zur dynamischen Außerbetriebnahme von Seiten von NVIDIA.

  Hinweis :Wenn ein nicht korrigierbarer ECC-Fehler auftritt, wird Ihr Arbeitslast beendet und die Anzahl der flüchtigen Fehler erhöht. In diesem Fall empfehlen wir, die GPU zurückzusetzen oder die Instanz neu zu starten und den Host nicht als fehlerhaft zu melden.

Xid-Mitteilungen prüfen

Wenn Sie schnell herausfinden möchten, warum eine GPU-Arbeitslast fehlgeschlagen ist, nicht mehr reagiert oder die Leistung nachgelassen hat, sehen Sie in den Kernel-Logs Ihrer Instanz (dmesg oder /var/log/kern.log) nach numerischen NVIDIA-Xid-Fehlercodes.

Die Tabellen mit Xid-Fehlern in den folgenden Unterabschnitten können Ihnen sofort helfen:

• Ursache ermitteln:Stellen Sie fest, ob der Fehler durch einen Anwendungsfehler (z. B. unzulässiger Speicherzugriff), einen Treiberkonflikt oder einen physischen Hardwarefehler (z. B. ECC-Speicherfehler mit zwei Bit) verursacht wird.
• Betriebliche Zuständigkeit ermitteln:Prüfen Sie, welche sofortigen manuellen Wiederherstellungsmaßnahmen Sie ergreifen müssen, z. B. GPUs zurücksetzen, VMs neu starten oder Debugger ausführen, im Vergleich zu automatischen Reparatur- und Hardwareaustauschmaßnahmen, die Google aktiv auf dem Host verwaltet.
• Die richtigen Schritte zur Wiederherstellung ausführen:Vermeide unnötige Fehlerbehebungsverfahren und wisse genau, wann eine manuelle Wiederherstellung ausreicht und wann du den Host als fehlerhaft melden musst. Manchmal reicht die manuelle Wiederherstellung nicht aus, z. B. wenn sich die Fehlerquelle im GPU-Cache (SRAM) befindet, der nicht neu zugeordnet werden kann (angegeben durch Xid 48 mit SRAM Threshold Exceeded=Yes), oder wenn die GPU ihren Remap-Bank erschöpft hat (angegeben durch Xid 64: All reserved rows for bank are remapped). In diesen Fällen erkennt Google, dass die GPU für einen Hardwareaustausch infrage kommt, und sendet die Maschine proaktiv zur Reparatur. Wenn bei Ihren Arbeitslasten wiederkehrende Fehler auftreten oder Sie wiederholt Speicherfehler feststellen, können Sie den fehlerhaften Host melden, um eine automatische Reparatur oder einen automatischen Austausch zu veranlassen. Informationen zu GKE finden Sie unter Fehlerhafte Hosts in GKE melden.

Xid-Verarbeitung

In den folgenden Abschnitten werden häufige Xid-Fehlermeldungen nach technischer Kategorie gruppiert. Außerdem werden die entsprechenden Lösungen und Verantwortlichkeiten aufgeführt:

• GPU-Speicherfehler (XIDs 48, 63, 64, 92, 94, 95)
• GSP-Fehler (GPU System Processor) (XIDs 119, 120)
• Fehler durch illegalen Speicherzugriff (XIDs 13, 31, 137)
• Weitere häufige Xid-Fehlermeldungen (Xids 74, 79, 109, 149)

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-Arbeitsspeicher ist durch den Fehlerkorrekturcode (Error Correction Code, ECC) geschützt, der Single-Bit-Fehler (Single-Bit Errors, SBE) erkennt und korrigiert und Double-Bit-Fehler (Double-Bit Errors, DBE) erkennt und meldet.

Diese Speicherfehler treten im Laufe der Lebensdauer einer GPU voraussichtlich auf. 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 für HBM-Fehler (DRAM) eingeführt. ECC ist standardmäßig aktiviert und Google empfiehlt dringend, ECC aktiviert zu lassen.

In der folgenden Tabelle sind häufige GPU-Arbeitsspeicherfehler und ihre empfohlenen Lösungen aufgeführt:

Xid-Fehlermeldung	Kundenaktion	Google-Aktion
Xid 48: Double Bit ECC Ein nicht korrigierbarer Speicherfehler mit zwei Bit wurde von ECC erkannt. Dieser Fehler unterbricht immer die laufende Arbeitslast und generiert die Xid 48.	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück oder starten Sie die VM neu, um Arbeitslasten wiederherzustellen und fortzusetzen. Das hängt von Ihrer Umgebung ab: Für Compute Engine-VMs:Setzen Sie die GPUs zurück oder starten Sie die VM neu. Weitere Informationen zu VM-Aktionen und Lebenszyklusstatus finden Sie unter Compute Engine-Instanzlebenszyklus. GKE-Knoten:Wenden Sie kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=true auf den betroffenen Knoten an, um einen Neustart des Gastbetriebssystems auszulösen.	Google überwacht, wann die GPU für einen Hardwareaustausch infrage kommt, z. B. wenn der HBM-Remap-Bank erschöpft ist oder die GPU den SRAM-Fehlerschwellenwert für die Lebensdauer überschreitet. In diesem Fall wird die Maschine proaktiv zur Reparatur gesendet, um die GPU zu ersetzen.
Xid 63: ECC page retirement or row remapping recording event Gibt an, dass aufgrund eines Speicherfehlers ein Ereignis zum Entfernen einer dynamischen Seite oder zum Neuzuordnen einer Zeile aufgezeichnet wurde.	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück oder starten Sie die VM neu, um Arbeitslasten wiederherzustellen und fortzusetzen. Das hängt von Ihrer Umgebung ab: Für Compute Engine-VMs:Setzen Sie die GPUs zurück oder starten Sie die VM neu. Weitere Informationen zu VM-Aktionen und Lebenszyklusstatus finden Sie unter Compute Engine-Instanzlebenszyklus. GKE-Knoten:Wenden Sie kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=true auf den betroffenen Knoten an, um einen Neustart des Gastbetriebssystems auszulösen.	Google überwacht die Fehlerschwellenwerte und sendet die Maschine zur Reparatur, wenn die GPU physisch repariert oder ausgetauscht werden muss.
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	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück oder starten Sie die VM neu, um Arbeitslasten wiederherzustellen und fortzusetzen. Das hängt von Ihrer Umgebung ab: Für Compute Engine-VMs:Setzen Sie die GPUs zurück oder starten Sie die VM neu. Weitere Informationen zu VM-Aktionen und Lebenszyklusstatus finden Sie unter Compute Engine-Instanzlebenszyklus. GKE-Knoten:Wenden Sie kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=true auf den betroffenen Knoten an, um einen Neustart des Gastbetriebssystems auszulösen.	Wenn der Remap-Speicher erschöpft ist (All reserved rows for bank are remapped), erkennt Google, dass die GPU für einen Hardware-Ersatz infrage kommt, und sendet die Maschine proaktiv zur Reparatur.
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	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück oder starten Sie die VM neu, um Arbeitslasten wiederherzustellen und fortzusetzen. Das hängt von Ihrer Umgebung ab: Für Compute Engine-VMs:Setzen Sie die GPUs zurück oder starten Sie die VM neu. Weitere Informationen zu VM-Aktionen und Lebenszyklusstatus finden Sie unter Compute Engine-Instanzlebenszyklus. GKE-Knoten:Wenden Sie kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=true auf den betroffenen Knoten an, um einen Neustart des Gastbetriebssystems auszulösen.	Google sendet die Maschine zur Reparatur, wenn der Remap-Bank erschöpft ist oder die GPU eine physische Reparatur oder einen Austausch erfordert.
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.	Kein
Xid 94: Contained error Gibt an, dass ein GPU-Fehler aufgetreten ist und ob der Fehler auf eine einzelne Anwendung beschränkt war. Allein gibt Xid 94 nicht die Ursache des Fehlers an. Es muss zusammen mit anderen gleichzeitig auftretenden Xid-Fehlern interpretiert werden, um die grundlegende Ursache zu ermitteln.	Da der Fehler in einer einzelnen Anwendung aufgetreten ist, starten Sie die Anwendung neu, um den Fehler zu beheben. Setzen Sie die GPUs bei Bedarf zurück oder beenden Sie Ihre Arbeitslasten. Untersuchen Sie andere gleichzeitig auftretende Xid-Fehler, um weitere Schritte zur Wiederherstellung und zur Ermittlung der Ursache zu finden.	Kein
Xid 95: Uncontained error Gibt an, dass ein GPU-Fehler aufgetreten ist, der nicht auf eine einzelne Anwendung beschränkt war. Allein gibt Xid 95 nicht die Ursache des Fehlers an. Es muss zusammen mit anderen gleichzeitig auftretenden Xid-Fehlern interpretiert werden, um die grundlegende Ursache zu ermitteln.	Da der Fehler nicht behoben wurde, müssen Sie Ihre Arbeitslasten beenden und die GPUs zurücksetzen oder die VM neu starten, um den Fehler zu beheben. Untersuchen Sie andere gleichzeitig auftretende Xid-Fehler, um die zugrunde liegende Ursache und weitere Schritte zur Fehlerbehebung zu ermitteln.	Kein

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	Kundenaktion	Google-Aktion
Xid 119: GSP RPC timeout	Beenden Sie Ihre Arbeitslasten. Prüfen Sie unter Empfohlene NVIDIA-Treiberzweige, ob Sie einen unterstützten Zweig und eine aktuelle oder die neueste Treiberversion verwenden, da Treiberfehler in früheren Versionen eine der Hauptursachen für GSP-Fehler sind. Wenn der Fehler nach dem Prüfen oder Aktualisieren des Treibers weiterhin besteht, 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.	Keine. Wenn der Fehler weiterhin auftritt und Sie eine Supportanfrage einreichen, untersucht Google im Rahmen des Supportverfahrens den Hardware- oder Treiberstatus.
Xid 120: GSP error

Ungültiger Arbeitsspeicherzugriff-Fehler

Die folgenden Xids werden zurückgegeben, wenn Anwendungen Fehler beim illegalen Arbeitsspeicherzugriff haben:

Xid-Fehlermeldung	Kundenaktion	Google-Aktion
Xid 13: Graphics Engine Exception Xid 31: GPU memory page fault Xid 137: Memory access fault Es wurde ein Arbeitsspeicherzugriffsfehler erkannt, der einem Segmentierungsfehler entspricht. Diese Fehler deuten in der Regel auf einen Anwendungsfehler hin, bei dem auf GPU-Arbeitsspeicher außerhalb des zulässigen Bereichs oder auf freigegebene Puffer zugegriffen wird, z. B. durch Dereferenzieren eines ungültigen Zeigers oder eines Arrays außerhalb des zulässigen Bereichs. Diese stellen keine ECC-Fehler dar, sofern nicht auch Xid 48 vorhanden ist.	Um dieses Problem zu beheben, müssen Sie die Speicherzugriffsfehler in Ihrer Anwendung debuggen. Sie können cuda-gdb, Compute Sanitizer oder cuda-memcheck verwenden. Weitere Informationen finden Sie in der NVIDIA Xid-Dokumentation.	Keine. In seltenen Fällen, in denen eine Hardwareverschlechterung fälschlicherweise gemeldete Fehler beim illegalen Speicherzugriff verursachen kann, können Sie NVIDIA Data Center GPU Manager (DCGM) verwenden, um dcgmi diag -r 3 oder dcgmi diag -r 4 für verschiedene Testabdeckungsgrade und ‑dauern auszuführen. Wenn Sie ein Hardwareproblem feststellen, erstellen Sie eine Anfrage beim Customer Care-Team.

Weitere häufige Xid-Fehlermeldungen

Xid-Fehlermeldung	Kundenaktion	Google-Aktion
Xid 74: NVLINK error	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück.	Kein
Xid 79: GPU has fallen off the bus Das bedeutet, dass der Treiber nicht mit der GPU kommunizieren kann, weil die GPU aufgrund eines Hardwareproblems vom PCI-Bus verschwunden ist.	Verwenden Sie einen der folgenden Ansätze, um Ihre Arbeitslasten wiederherzustellen. Das hängt davon ab, ob Notfallwartung für Ihr Projekt aktiviert ist: Notfallwartung anfordern:Wenn die Notfallwartung für Ihr Projekt eingeführt wird, können Sie das Wartungsereignis nach Bedarf auslösen. Auf automatische Wartung warten:Andernfalls warten Sie auf ein ungeplantes Wartungsereignis für die Instanz.	Google erkennt, dass die GPU vom PCI-Bus getrennt wurde, und sendet die Maschine zur Reparatur.
Xid 109: Context switch timeout Xid 109 ist ein generischer Fehler, der vom NVIDIA-GPU-Treiber gemeldet wird. Er wird generiert, wenn eine GPU-Instanz Aufgaben nicht innerhalb des erwarteten Zeitlimits unterbrechen oder wechseln kann. Google hat Xid 109 schon oft mit NVIDIA untersucht. Bekannte Ursachen, die auf Treiberfehler zurückzuführen sind, wurden in den neuesten Treibern behoben. Xid 109 wird nicht durch ein Hardwareproblem verursacht.	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück oder starten Sie die VM neu, um Arbeitslasten wiederherzustellen und fortzusetzen. Das hängt von Ihrer Umgebung ab: Für Compute Engine-VMs:Setzen Sie die GPUs zurück oder starten Sie die VM neu. Weitere Informationen zu VM-Aktionen und Lebenszyklusstatus finden Sie unter Compute Engine-Instanzlebenszyklus. GKE-Knoten:Wenden Sie kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=true auf den betroffenen Knoten an, um einen Neustart des Gastbetriebssystems auszulösen. Erwägen Sie ein Upgrade auf eine neuere NVIDIA-Treiberversion für Ihre Umgebung, z. B. Installation des neuesten Treibers auf Ihrer Compute Engine-VM oder Upgrade Ihres GKE-Knotenpools/Treiber-DaemonSets.	Kein
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.	Beenden Sie Ihre Arbeitslasten. Setzen Sie die GPUs zurück.	Kein

GPUs zurücksetzen

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

• Starten Sie für N1-, G2-, A2- und G4-VMs mit einer oder mehreren angehängten GPUs die VM neu.
• Führen Sie für G4-VMs mit fraktionierten GPUs (weniger als eine angehängte GPU) die folgenden Schritte aus:
  1. Löschen Sie die VM.
  2. Erstellen Sie die VM neu.
• Führen Sie für A3-, A4-, A4X- und A4X Max-Instanzen 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.
• Für A3-, A4-, A4X- und A4X Max-Instanzen auf GKE-Knoten können Sie auch 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 beenden und neu starten. Weitere Informationen zu VM-Lebenszyklusstatus und den Unterschieden zwischen VM-Wiederherstellungsaktionen finden Sie unter Lebenszyklus von Compute Engine-Instanzen und Compute Engine-Instanzen sperren, beenden oder zurücksetzen.

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 des Projekts, in dem sich die betroffenen Instanzen befinden.
• 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.

Nächste Schritte

GPUMaschinentypen ansehen