Compute Engine-Instanzen und Slurm-Cluster überwachen

In diesem Dokument wird beschrieben, wie Sie mit Cloud Monitoring-Dashboards A4X Max-, A4X-, A4-, A3 Ultra- und A3 Mega-Instanzen überwachen, die Sie mit reservierungsgebundener Kapazität erstellt haben. Mithilfe dieser Dashboards können Sie Leistungsengpässe in Ihren eigenständigen Compute Engine-Instanzen oder Slurm-Clustern identifizieren und beheben und so die Ausfallzeiten Ihrer Arbeitslasten minimieren.

Wenn Sie benutzerdefinierte Dashboards erstellen oder vordefinierte Monitoring-Dashboards verwenden, können Sie Folgendes überwachen:

  • Zustand der Compute-Instanz

  • GPU-Leistung

  • Effizienz der Netzwerkübertragung

  • Netzwerkeffizienz zwischen Blöcken und Unterblöcken

  • Effizienz von Arbeitslasten für maschinelles Lernen (ML)

  • Nachzüglererkennung

  • Erkennung nicht reagierender Arbeitslasten

Informationen zum Überwachen von Cluster Director-Clustern finden Sie unter Clusterleistung mit vordefinierten Dashboards überwachen.

Hinweis

Führen Sie die folgenden Schritte aus, bevor Sie Ihre Arbeitslast überwachen, falls Sie dies noch nicht getan haben:

Wenn Sie über die Google Cloud Console auf Dienste und APIs von Google Cloud zugreifen, müssen Sie die Authentifizierung nicht einrichten.

Beschränkungen

  • Die Messwerte in diesem Dokument werden nur für Arbeitslasten unterstützt, die auf Compute-Instanzen ausgeführt werden, die alle folgenden Kriterien erfüllen:

    • Die Compute-Instanzen müssen entweder als eigenständige Compute Engine-Instanzen oder als Teil eines Slurm-Clusters erstellt werden.
    • Die Compute-Instanzen müssen mit reservierungsgebundener Kapazität erstellt worden sein.
    • Die Compute-Instanzen müssen die Maschinenserie A4X Max, A4X, A4, A3 Ultra oder A3 Mega verwenden.
      • Die Straggler-Erkennung unterstützt jedoch auch VM-Instanzen, die die Maschinenserie A3 Mega verwenden.

Wenn Sie Messwerte für ML-Arbeitslasten überwachen möchten, müssen Sie das Monitoring für Ihre Arbeitslast einrichten.

Einschränkungen bei der Erkennung von Nachzüglern

Für Messwerte zur Straggler-Erkennung gelten die folgenden zusätzlichen Einschränkungen:

  • Für andere unterstützte Maschinenserien als A3 Mega unterstützt die Straggler-Erkennung nur Compute-Instanzen, die die Collective Communication Analyzer-Bibliothek (CoMMA) aktivieren, um NCCL-Telemetriedaten in Google Cloud -Dienste zu exportieren. Weitere Informationen finden Sie in der CoMMA-Übersicht.
  • Die Straggler-Erkennung benötigt in der Regel bis zu 10 Minuten, um einen Straggler zu melden.
  • Im Gegensatz zu den anderen Messwerten in diesem Dokument können Sie die Messwerte zur Erkennung von Nachzüglern für Ihre Projekte nicht nach Cluster, Block, Unterblock oder Compute-Instanz filtern. Sie können jedoch Abfragen für Logs zur Erkennung von Nachzüglern nach der ID einer oder mehrerer Compute-Instanzen filtern, die als Nachzügler vermutet werden.

Einschränkungen bei der Erkennung nicht reagierender Arbeitslasten

Messwerte zur Erkennung nicht reagierender Arbeitslasten unterstützen nur Compute-Instanzen, die die CoMMA-Bibliothek (Collective Communication Analyzer) verwenden, um NCCL-Telemetriedaten in Google Cloud -Dienste zu exportieren. Weitere Informationen finden Sie in der CoMMA-Übersicht.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Überwachen von Messwerten für AI Hypercomputer-Arbeitslasten benötigen:

  • Zum Aufrufen von Messwerten in Cloud Monitoring: Monitoring-Bearbeiter (roles/monitoring.editor) für das Projekt
  • So rufen Sie Logs zur Straggler-Erkennung in Logging auf: Loganzeige (roles/logging.viewer) für das Projekt

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Überwachen von Messwerten für AI Hypercomputer-Arbeitslasten erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um Messwerte für AI Hypercomputer-Arbeitslasten zu überwachen:

  • Zum Aufrufen von Dashboards: monitoring.dashboards.get für das Projekt
  • Zum Erstellen von Dashboards: monitoring.dashboards.create für das Projekt
  • So rufen Sie Logeinträge auf: logging.logEntries.list für das Projekt

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Verfügbare Messwerte

Je nach Anwendungsfall stehen die folgenden Messwerte für das Monitoring Ihrer Compute-Instanzen und Slurm-Cluster zur Verfügung:

  • Informationen zum Überwachen des Zustands, der Leistung und der Netzwerkleistung der GPUs, die an Ihre Compute-Instanzen angehängt sind, finden Sie unter Infrastrukturmesswerte.

  • Informationen zum Überwachen der Effizienz der GPUs in Ihren ML-Arbeitslasten finden Sie unter Messwerte für ML-Arbeitslasten.

  • Informationen zum Überwachen von mutmaßlichen Nachzügler-Compute-Instanzen in ML-Arbeitslasten mit langsamer Leistung finden Sie unter Messwerte zur Nachzüglererkennung.

Informationen zum Aufrufen dieser Messwerte finden Sie in diesem Dokument unter Messwerte visualisieren.

Infrastrukturmesswerte

Mit den folgenden Messwerten können Sie den Zustand, die Leistung und die Netzwerkleistung der GPUs überwachen, die an Ihre Compute-Instanzen angehängt sind:

Eine Übersicht über die in Compute Engine verfügbaren Messwerte finden Sie unter Google Cloud -Messwerte.

GPU-Zustandsmesswerte

Verwenden Sie die folgenden Messwerte, um den Zustand Ihrer GPUs zu überwachen:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Maschinenstatus machine/machine_status A4X Max, A4X, A4, A3 Ultra oder A3 Mega Ob die Maschine, die die Compute-Instanz verwendet, fehlerfrei ist oder ob sie fehlerhaft ist und repariert werden muss.
NVSwitch-Status instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra oder A3 Mega Ob bei einem NVLink-Switch auf einer NVIDIA-GPU, die an eine Compute-Instanz angehängt ist, Probleme auftreten.
VM-Infrastrukturzustand instance/gpu/infra_health A4X, A4, A3 Ultra oder A3 Mega Der Zustand des Clusters, Blocks, Unterblocks und Hosts, auf dem Ihre Compute-Instanzen ausgeführt werden. Wenn dieser Messwert zeigt, dass die Infrastruktur einer Compute-Instanz fehlerhaft ist, wird das Problem auch im Messwert beschrieben.
VM-Fehlervorhersagewert instance/gpu/failure_prediction_score A4X, A4, A3 Ultra oder A3 Mega Die Wahrscheinlichkeit, dass sich die Leistung des Hosts, auf dem die Compute-Instanz ausgeführt wird, in den nächsten fünf Stunden verschlechtert. Der Wert kann im Bereich von 0.0 bis 1.0 liegen. Je näher der Wert über einen längeren Zeitraum an 1.0 liegt, desto wahrscheinlicher ist es, dass die Leistung der Compute-Instanz beeinträchtigt wird. In diesem Fall empfehlen wir, den Job auf eine andere Compute-Instanz zu verschieben. Wenn Probleme mit der Compute-Instanz auftreten, melden Sie den Host als fehlerhaft.

GPU-Leistungsmesswerte

Verwenden Sie die folgenden Messwerte, um die Leistung Ihrer GPUs zu überwachen:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Kumulierte Kontextauslastung instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die Gesamtzeit in Sekunden, die die GPU mit der Verarbeitung einer Arbeitslast beschäftigt ist.
GPU-Stromverbrauch instance/gpu/power_consumption A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die Leistung in Watt (W) und in Dezimalwerten, die von einzelnen GPUs auf dem Host verbraucht wird. Bei Compute-Instanzen mit mehreren angehängten GPUs wird der Stromverbrauch für jede GPU auf dem Host separat angegeben.
SM-Auslastung instance/gpu/sm_utilization A4X Max, A4X, A4, A3 Ultra oder A3 Mega Ein Wert ungleich null gibt an, dass die Streaming-Multiprozessoren (SMs) auf Ihren GPUs aktiv verwendet werden.
GPU-Temperatur instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die Temperatur in Celsius (℃) und in Dezimalwerten einzelner GPUs auf dem Host. Bei Compute-Instanzen mit mehreren angehängten GPUs wird die Temperatur für jede GPU auf dem Host separat angegeben.
GPU-Wärmemarge instance/gpu/tlimit A4X Max, A4X, A4, A3 Ultra oder A3 Mega Der thermische Spielraum in Celsius (℃) und in Dezimalwerten, den einzelne GPUs haben, bevor sie aufgrund hoher Temperaturen langsamer werden müssen. Bei Compute-Instanzen mit mehreren angehängten GPUs wird der thermische Spielraum für jede GPU auf dem Host separat angegeben.

Leistungsmesswerte für GPU-Netzwerke

Verwenden Sie die folgenden Messwerte, um die Netzwerkleistung Ihrer GPUs zu überwachen. Informationen zum Monitoring von ToR-Netzwerk-Switches im Backend finden Sie unter ToR-Switch-Messwerte.

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Änderungen am Link-Mobilfunkanbieter instance/gpu/link_carrier_changes A4X, A4, A3 Ultra oder A3 Mega Wie oft sich der Netzwerkanbieter pro Minute ändert.
Netzwerk-RTT instance/gpu/network_rtt A4X, A4, A3 Ultra oder A3 Mega Die Umlaufzeit in Mikrosekunden, die Netzwerkdaten für die Übertragung zwischen einer Quelle und einem Ziel benötigen.
Netzwerkverkehr zwischen Blöcken instance/gpu/network/inter_block_tx A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte des Netzwerkverkehrs zwischen Blöcken.
Netzwerktraffic zwischen Subblöcken instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte des Netzwerkverkehrs zwischen Unterblöcken.
Netzwerkverkehr im Subblock instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte des Netzwerkverkehrs innerhalb eines einzelnen Unterblocks.
Aktive NVLink-Geschwindigkeit instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die aktuelle Portgeschwindigkeit des Zugriffslinks in Gbit/s.
Durchsatz-RX-Bytes instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte, die über den Netzwerkverkehr empfangen wurden.
Durchsatz-TX-Bytes instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte, die an den Netzwerkverkehr übertragen wurden.

ToR-Switch-Messwerte

Bei A4X Max- und A4X-Clustern können Sie die Telemetrie des Backend-ToR-Netzwerk-Switches überwachen, um während des verteilten ML-Trainings Folgendes zu tun:

  • Zustand von Switch und Port beobachten.
  • Verfügbare Bandbreitenkapazität und Tiefe der Warteschlange bewerten.
  • Diagnostizieren Sie Paketverluste, Fehler, Schnittstellen-Flaps und Ereignisse im Zusammenhang mit der Überlastungsverwaltung.

Diese Messwerte verwenden den überwachten Ressourcentyp compute.googleapis.com/NetworkSwitch und das Messwerttyppräfix compute.googleapis.com/. Wählen Sie im Metrics Explorer den Ressourcentyp NetworkSwitch (compute.googleapis.com/NetworkSwitch) aus.

Die Messwerte für den Wechsel sind in folgende Kategorien unterteilt:

Gesundheits- und Statusmesswerte wechseln

Mit den in diesem Abschnitt aufgeführten Messwerten können Sie Folgendes tun:

  • Betriebsstatus von Switch-Ports prüfen
  • CPU- und Arbeitsspeicherauslastung des Switches überwachen.
  • Prüfen Sie die Bootzeiten, um unerwartete Neustarts zu erkennen.
Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Status der Nummernmitnahme network_switch/port_status A4X Max oder A4X Gibt den Betriebsstatus der physischen Schnittstelle (Port) auf dem Netzwerk-Switch an. Der Messwert ist für die Aggregation immer 1. Der tatsächliche Status wird im Label status angegeben (z. B. UP oder DOWN).
Wichtige Labels: port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
CPU-Auslastung network_switch/cpu_utilization A4X Max oder A4X Die CPU-Auslastung des Netzwerk-Switches, gemessen als Bruchteil von 0.0 bis 1.0.
Schlüssellabels: subblock_id, block_id, reservation_id, switch_type.
Verwendeter Arbeitsspeicher network_switch/memory_used A4X Max oder A4X Der vom Netzwerk-Switch verwendete Arbeitsspeicher in Byte.
Schlüssellabels: subblock_id, block_id, reservation_id, switch_type.
Arbeitsspeicher insgesamt network_switch/total_memory_bytes A4X Max oder A4X Die Gesamtspeicherkapazität des Netzwerk-Switches in Byte.
Schlüssellabels: subblock_id, block_id, reservation_id, switch_type.
Bootzeit network_switch/boot_time_in_ns A4X Max oder A4X Der Boot-Zeitstempel des Netzwerk-Switches in Nanosekunden seit der Unix-Epoche.
Schlüssellabels: subblock_id, block_id, reservation_id, switch_type.
Messwerte für Switch-Kapazität und ‑Warteschlange

Verwenden Sie die folgenden Messwerte, um die Referenz- und die nutzbare Netzwerkkapazität zu verfolgen und die Tiefe der Warteschlange und die Anzahl der verworfenen Pakete auf dem Switch zu überwachen:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Referenzkapazität network_switch/baseline_capacity_kbps A4X Max oder A4X Die gesamte potenzielle Bandbreitenkapazität (Baseline) einer ToR-Switch-Verbindung zum Superblock in Kilobit pro Sekunde (kbit/s).
Schlüssellabels: subblock_id, block_id, reservation_id, switch_type.
Effektive Kapazität network_switch/effective_capacity_kbps A4X Max oder A4X Die nutzbare Betriebskapazität einer ToR-Switch-Verbindung zum Superblock in Kilobit pro Sekunde (kbit/s). Dieser Messwert spiegelt Kapazitätsreduzierungen wider, die durch beeinträchtigte oder Offline-Links verursacht werden.
Schlüssellabels: subblock_id, block_id, reservation_id, switch_type.
Maximale Tiefe der Warteschlange für ausgehenden Traffic network_switch/egress_max_queue_depth A4X Max oder A4X Die maximale Warteschlangentiefe, die während des letzten Messzyklus beobachtet wurde.
Wichtige Labels: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Verworfene Pakete in der Warteschlange für ausgehenden Traffic network_switch/egress_queue_drops_count A4X Max oder A4X Die kumulative Anzahl der Pakete, die aufgrund von Warteschlangenüberlastung oder Pufferauslastung aus Warteschlangen für ausgehenden Traffic verworfen wurden.
Wichtige Labels: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Verworfene Pakete im Zwischenspeicher network_switch/in_buffer_discards A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die beim Eingang aufgrund eines Pufferüberlaufs verworfen wurden.
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Messwerte zu Switch-Drops, Fehlern und Flusssteuerung

Verwenden Sie die Messwerte in diesem Abschnitt, um die folgenden Probleme zu diagnostizieren, die zu Stillständen beim verteilten Training oder zu Zeitüberschreitungen bei der kollektiven Kommunikation (z. B. NCCL-Watchdog-Zeitüberschreitungen) führen können:

  • Paketverluste, Übertragungsfehler und physische Verbindungsabbrüche.
  • FEC-Wortfehler (Forward Error Correction)
  • Ereignisse zur Überlastungsverwaltung, z. B. Pausen bei der prioritätsbasierten Flusssteuerung (Priority-based Flow Control, PFC) und Markierungen für die explizite Überlastungsbenachrichtigung (Explicit Congestion Notification, ECN).
Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Schnittstellenklappen network_switch/interface_flaps_count A4X Max oder A4X Die kumulative Anzahl der Zustandsübergänge der physischen Verbindung (Wechsel zwischen UP und DOWN) auf der Switch-Port-Schnittstelle.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.
FEC-Wortfehler network_switch/fec_word_error_count A4X Max oder A4X Die kumulative Anzahl der FEC-Wortfehler (Forward Error Correction). Verwenden Sie das boolesche Label correctable (true oder false), um zwischen korrigierbaren und nicht korrigierbaren Fehlern zu unterscheiden.
Wichtige Labels: port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
ECN-markierte Pakete network_switch/ecn_marked_packets_count A4X Max oder A4X Die kumulative Anzahl der Pakete, die aufgrund von Überschreitungen des Pufferschwellenwerts mit ECN-Bits (Explicit Congestion Notification) gekennzeichnet sind.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pfc rx-Pakete network_switch/pfc_rx_packets_count A4X Max oder A4X Die kumulative Anzahl der auf dem Port empfangenen Pause-Frames für die prioritätsbasierte Flusssteuerung (Priority-based Flow Control, PFC).
Hinweis: Gilt nur für dedizierte Umgebungen, in denen PFC aktiviert ist.
Wichtige Labels: port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
PFC-TX-Pakete network_switch/pfc_tx_packets_count A4X Max oder A4X Die kumulative Anzahl der Pause-Frames der prioritätsbasierten Flusssteuerung (PFC), die vom Port übertragen werden, um eingehenden Traffic zu drosseln.
Hinweis: Gilt nur für dedizierte Umgebungen, in denen PFC aktiviert ist.
Wichtige Labels: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
QoS-TX-Pakete network_switch/qos_tx_packets A4X Max oder A4X Die kumulative Anzahl der QoS-Pakete (Quality of Service), die in der angegebenen Warteschlange übertragen wurden.
Wichtige Labels: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Anzahl der eingehenden Pakete network_switch/in_packets_count A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die am Switch-Port empfangen wurden.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.
In Fehlern network_switch/in_errors A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die mit Fehlern empfangen wurden, die ihre Zustellung verhindert haben.
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
In „Verworfen“ network_switch/in_discards A4X Max oder A4X Die kumulative Anzahl der gültigen eingehenden Pakete, die verworfen wurden (z. B. aufgrund von fehlendem Zwischenspeicher).
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Ausgangsfehler network_switch/out_errors A4X Max oder A4X Die kumulative Anzahl der ausgehenden Pakete, die aufgrund von Fehlern nicht übertragen werden konnten.
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Ausgehende verworfene Pakete network_switch/out_discards A4X Max oder A4X Die kumulative Anzahl der ausgehenden Pakete, die verworfen wurden, obwohl keine Fehler erkannt wurden.
Schlüssellabels: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Anzahl der eingehenden Bytes network_switch/in_bytes_count A4X Max oder A4X Die kumulative Anzahl der eingehenden Bytes, die am Switch-Port empfangen wurden.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Anzahl der ausgehenden Bytes network_switch/out_bytes_count A4X Max oder A4X Die kumulative Anzahl der ausgehenden Byte, die über den Switch-Port übertragen wurden.
Wichtige Labels: port_identifier, subblock_id, block_id, reservation_id, switch_type.

Messwerte zu schwerwiegenden GPU-Fehlern

Mit den folgenden Messwerten können Sie die Fehler überwachen, die bei Ihren GPUs auftreten und die dazu führen können, dass Ihre Compute-Instanzen beendet werden oder ihre Leistung beeinträchtigt wird:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
NVLink-Laufzeitfehler instance/gpu/nvlink_runtime_error A4X Max oder A4X Gibt an, ob ein NVLink-Laufzeitfehler aufgetreten ist.
Nicht korrigierbare DRAM-ECC-Fehler instance/gpu/dram_uncorrectable_ecc_error_count A4X Max oder A4X Die Anzahl der nicht korrigierbaren Fehlerkorrekturcodes (ECCs) in einem GPU-DRAM (Dynamic Random Access Memory).
Anzahl der nicht korrigierbaren DRAM-Zeilenneuzuordnungen instance/gpu/dram_uncorrectable_row_remapping_count A4X Max oder A4X Die Anzahl der Zeilenneuzuordnungen aufgrund nicht korrigierbarer Fehler in GPU-DRAMs.
Nicht korrigierbare DRAM-Zeilenneuzuordnung fehlgeschlagen instance/gpu/dram_row_remapping_failed A4X Max oder A4X Gibt an, ob eine Zeilenneuzuordnung in GPU-DRAMs aufgrund eines der folgenden Probleme fehlgeschlagen ist:
  • Ein Neuzuordnungsversuch für eine Memory Bank ist fehlgeschlagen, da die Memory Bank bereits acht nicht korrigierbare Fehlerzeilen neu zugeordnet hat.
  • Ein Versuch, eine Zeile neu zuzuordnen, ist fehlgeschlagen, da die Zeile bereits neu zugeordnet wurde.
  • Ein Neuzuordnungsversuch ist fehlgeschlagen, da insgesamt 512 Neuzuordnungen vorgenommen wurden.
Nicht korrigierbare PCIe-Fehler instance/gpu/pcie_fatal_error_count A4X Max oder A4X Die Anzahl der nicht korrigierbaren PCIe-Fehler (Peripheral Component Interconnect Express).
Nicht korrigierbare Cache-ECC-Fehler instance/gpu/cache_uncorrectable_ecc_error_count A4X Max oder A4X Die Anzahl der nicht korrigierbaren ECCs im Cache-Speicher.

ML-Arbeitslastmesswerte

Wenn Sie die Produktivität – insbesondere den Goodput – Ihrer ML-Arbeitslasten überwachen möchten, verwenden Sie die folgenden Messwerte:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Produktive Zeit workload/goodput_time A4X, A4, A3 Ultra oder A3 Mega Die Zeit in Sekunden, die die Arbeitslast für Goodput-Aktivitäten aufwendet. Diese Aktivitäten sind wichtige, nützliche Aufgaben, z. B. ein Vorwärts- oder Rückwärtsdurchlauf während des Modelltrainings.
Unproduktive Zeit workload/badput_time A4X, A4, A3 Ultra oder A3 Mega Die Zeit in Sekunden, die die Arbeitslast für Badput-Aktivitäten aufwendet. Diese Aktivitäten sind Overhead-Aufgaben, z. B. das Laden oder Vorverarbeiten von Daten für das Training.

Messwerte zur Erkennung von Nachzüglern

Mithilfe von Messwerten zur Erkennung von Nachzüglern können Sie mutmaßliche Nachzügler erkennen und lokalisieren. Nachzügler sind einzelne, nicht abstürzende Fehler, die letztendlich die gesamte Arbeitslast verlangsamen.

Verwenden Sie den folgenden Messwert, um die Straggler-Erkennung für Ihre VMs zu überwachen:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Verdächtige Nachzügler instance/gpu/straggler_status A4X, A4, A3 Ultra oder A3 Mega Ob eine VM als Nachzügler vermutet wird, der die Leistung der Arbeitslast beeinträchtigt. Wir empfehlen, nur dann auf vermutete Nachzügler zu reagieren, wenn andere Messwerte darauf hindeuten, dass bei der Arbeitslast Probleme auftreten.

Sie können sich auch Messwerte zur Erkennung von Nachzüglern in den Logeinträgen für eine A4X-, A4-, A3 Ultra- oder A3 Mega-Instanz ansehen. Sie können beispielsweise die folgenden Abfragen verwenden:

Beschreibung Abfrage
Logs mit mutmaßlichen Nachzüglern für bestimmte VMs. Mit dieser Abfrage können Sie prüfen, ob es in Ihrem Projekt mutmaßliche Nachzügler für eine bestimmte Arbeitslast gibt. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

Ersetzen Sie INSTANCE_ID durch die ID einer VM. Fügen Sie für jede zusätzliche VM, die Sie angeben möchten, die folgende Bedingung zur Abfrage hinzu:

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Alle Logs aus der Straggler-Erkennung für Ihr Projekt. Mit dieser Abfrage können Sie prüfen, ob der Dienst zur Erkennung von Nachzüglern ausgeführt wird, wenn keine mutmaßlichen Nachzügler erkannt werden. Aufgrund der Einschränkungen können Sie die Logs ohne verdächtige Nachzügler nicht nach bestimmten VMs filtern. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Messwerte zur Straggler-Erkennung sind aus folgenden Gründen besonders hilfreich für große ML-Arbeitslasten:

  • Umfangreiche ML-Arbeitslasten sind sehr anfällig für Nachzügler. Bei umfangreichen ML-Arbeitslasten wird synchrones und massiv verteiltes Computing verwendet. (Mit anderen Worten: Sie haben viele, stark voneinander abhängige Komponenten, die gleichzeitig ausgeführt werden.) Diese Architektur macht umfangreiche ML-Arbeitslasten sehr anfällig für Single-Point-of-Failure-Probleme wie Nachzügler.

  • Es ist sehr schwierig, Nachzügler in umfangreichen ML-Arbeitslasten zu erkennen und zu lokalisieren. Es gibt zwei Arten von Single-Point-of-Failure-Fehlern:

    • Stoppfehler: Fehler, die dazu führen, dass das gesamte System angehalten wird, z. B. Hostfehler und Wartungsereignisse. Sie sind relativ einfach zu erkennen und zu beheben.

    • Langsame Fehler: Fehler, die zu einer erheblichen Leistungsminderung ohne Abstürze führen. Sie sind sehr schwer zu lokalisieren und zu beheben.

    Aufgrund ihrer langsamen Ausfallnatur sind Nachzügler von Natur aus schwer zu erkennen und zu lokalisieren, insbesondere bei umfangreichen synchronen Arbeitslasten.

Messwerte zur Erkennung nicht reagierender Arbeitslasten

Messwerte zur Erkennung nicht reagierender Arbeitslasten helfen Ihnen bei Folgendem:

  • Erkennen, wenn eine gesamte Arbeitslast blockiert ist (manchmal als NCCL-Blockierung bezeichnet)
  • Gründe für das Stocken der Arbeitslast, z. B. ob es durch einen Prozessabsturz oder ein blockiertes Netzwerk verursacht wurde

Verwenden Sie die folgenden Messwerte, um nicht reagierende Arbeitslasten für Ihre Compute-Instanzen zu erkennen und zu diagnostizieren:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Nicht reagierende Arbeitslasten mithilfe von NCCL-Telemetrie erkennen instance/gpu/nccl_hang A4X Max, A4X, A4 und A3 Ultra Die Anzahl der erkannten nicht reagierenden Arbeitslast-Ereignisse als Zeitreihe.

Erkennung nicht reagierender Arbeitslasten aktivieren

Wenn Sie die Erkennung nicht reagierender Arbeitslasten aktivieren möchten, müssen Sie CoMMA mit Heartbeat-Telemetrie aktivieren. Dabei handelt es sich um ein regelmäßiges Ping-Signal, das angibt, dass eine Arbeitslast ausgeführt wird. In aktuellen Versionen von CoMMA ist diese Option standardmäßig aktiviert. Wenn Sie jedoch die CoMMA-Version aus Version 1.1.1 des NICCL/gIB-Bundles verwenden, müssen Sie die Heartbeat-Telemetrie manuell aktivieren. Informationen dazu, welche Version des NICCL/gIB-Bundles Sie verwenden, finden Sie unter NCCL- und gIB-Version prüfen.

Wenn Sie die Heartbeat-Telemetrie für CoMMA manuell aktivieren möchten, geben Sie die folgenden Umgebungsvariablen in Ihrer Trainingsumgebung an:

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Verwenden Sie NCCL_PROFILER_HEARTBEAT, um die Heartbeat-Telemetrie zu aktivieren oder zu deaktivieren, und NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL, um die Häufigkeit der Heartbeat-Telemetrie anzugeben. Weitere Informationen finden Sie unter CoMMA-Umgebungsvariablen.

Erkennung nicht reagierender Arbeitslasten deaktivieren

Wenn Sie die Erkennung nicht reagierender Arbeitslasten deaktivieren möchten, deaktivieren Sie die Heartbeat-Telemetrie in CoMMA. Geben Sie dazu die folgende Umgebungsvariable in Ihrer Trainingsumgebung an:

NCCL_PROFILER_HEARTBEAT=false

Gründe für nicht reagierende Arbeitslasten

Wenn Sie wissen möchten, warum eine Arbeitslast nicht reagiert, prüfen Sie den Wert des Labels hang_reason. Gehen Sie dazu so vor:

  1. Rufen Sie in der Google Cloud Console das auf der Seite des Metrics Explorer auf:

    Zu Metrics Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  2. Suchen Sie nach dem folgenden Messwert:

    compute.googleapis.com/instance/gpu/nccl_hang

  3. Verwenden Sie die Funktion Aggregation und wählen Sie die folgenden Labels aus:

    • instance_id
    • hang_reason

In der folgenden Tabelle sind mögliche Werte für das Label aufgeführt, was diese Werte für Ihre Arbeitslasten bedeuten und welche nächsten Schritte empfohlen werden.

Labelwert Beschreibung Empfehlungen
MissingHeartbeatIssue Die Heartbeat-Telemetrie wurde für einen oder mehrere Ränge beendet, was in der Regel auf einen schwerwiegenden Prozess- oder Knotenabsturz hinweist.
  • Prüfen Sie, ob die Instanz noch erreichbar ist.
  • Prüfen Sie, ob Arbeitslastprozesse abgestürzt sind.
  • Suchen Sie in den Systemprotokollen nach OOM-Ereignissen (Out-of-Memory), z. B. dmesg.
  • Suchen Sie nach Hardwarefehlern oder NVIDIA-XID-Fehlern.
StalledRankIssue Heartbeat-Telemetriedaten werden weiterhin empfangen, aber die Ränge machen bei NCCL-Vorgängen keine Fortschritte.
  • Untersuchen Sie potenzielle Deadlocks bei Vorgängen auf Anwendungsebene.
  • Prüfen Sie, ob der Anwendungsprozess in einem Vorgang hängen geblieben ist, der die Kommunikation mit anderen verhindert, z. B. bei einer Berechnung oder einem Checkpointer.
MissingCommunicatorIssue Alle Ränge, die zu einem NCCL-Kommunikator gehören, haben aufgehört, Fortschritte zu machen.
  • Ihre Arbeitslast wurde möglicherweise unterbrochen oder die NCCL-Kommunikatoren wurden abrupt geschlossen. Wenn Sie erwarten, dass eine Arbeitslast auf dieser VM-Instanz ohne Unterbrechung ausgeführt wird, prüfen Sie, ob die Arbeitslast ungewöhnlich unterbrochen oder beendet wurde.
NoHangIssue Der Standardwert. Es wurden keine Probleme gefunden.
  • Sie müssen nichts weiter tun.

Messwerte aufrufen

So rufen Sie Messwerte für Ihre Compute-Instanzen und Slurm-Cluster auf:

Wenn bei der Verwendung eines Dashboards Probleme auftreten, lesen Sie den Hilfeartikel Fehlerbehebung bei langsamer Leistung.

Vordefinierte Dashboards verwenden

Sie können vordefinierte Monitoring-Dashboards für AI Hypercomputer verwenden, um Messwerte für Ihre Compute-Instanzen und Slurm-Cluster aufzurufen. Sie können auch eine Kopie eines vordefinierten Dashboards erstellen und an Ihre Anforderungen anpassen.

So verwenden Sie ein vordefiniertes Dashboard für AI Hypercomputer:

  1. Öffnen Sie in der Google Cloud Console die Seite Dashboards :

    Zu Dashboards

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  2. Klicken Sie in der Spalte Name auf den Namen eines der folgenden Dashboards, je nachdem, welche Messwerte Sie sich ansehen möchten:

    • Verwenden Sie das Dashboard Cluster Director Health Monitoring, um den Zustand von Compute-Instanzen, die GPU-Leistung und die Erkennung von Stragglern zu überwachen.

      Weitere Informationen dazu, wie Sie diese Messwerte verwenden, um Probleme zu identifizieren und zu analysieren, finden Sie auch im Playbook-Dashboard GCE Interactive Playbook – Cluster Director Health Monitoring.

    • Verwenden Sie das Dashboard Cluster Director Transmission Efficiency, um die Effizienz der Netzwerkübertragung zu überwachen.

    • Verwenden Sie das Dashboard Cluster Director Block Network, um die Netzwerkeffizienz zwischen Blöcken und Unterblöcken zu überwachen.

      Weitere Informationen dazu, wie Sie diese Messwerte verwenden, um Probleme zu identifizieren und zu analysieren, finden Sie im Playbook-Dashboard GCE Interactive Playbook – Cluster Director Block Network.

    Die Detailseite des ausgewählten Dashboards wird geöffnet. Mit der Zeitraumauswahl in der Symbolleiste können Sie den Zeitraum der Daten ändern.

  3. Optional: Wenn Sie eine Kopie eines Dashboards erstellen und an Ihre Anforderungen anpassen möchten, klicken Sie auf Dashboard kopieren.

Benutzerdefinierte Dashboards erstellen

So erstellen Sie ein benutzerdefiniertes Monitoring-Dashboard:

  1. Wählen Sie die zu überwachenden Messwerte aus. Falls noch nicht geschehen, lesen Sie den Abschnitt Verfügbare Messwerte in diesem Dokument.

  2. Benutzerdefinierte Dashboards erstellen und verwalten

Logs zur Nachzüglererkennung ansehen

Führen Sie die folgenden Schritte aus, um Logs zur Nachzüglererkennung mit dem Log-Explorer aufzurufen:

  1. Rufen Sie in der Google Cloud Console das und die Seite Log-Explorer auf:

    Zum Log-Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis mit der Zwischenüberschrift Logging aus.

    Auf der Seite werden standardmäßig alle Logs in Ihrem Projekt abgefragt. Klicken Sie auf Abfrage beenden.

  2. Wählen Sie in der Symbolleiste mit der Zeitraumauswahl den Zeitraum aus, den Sie analysieren möchten.

  3. Geben Sie im Bereich Abfrage eine Abfrage für Logs zur Erkennung von Nachzüglern ein.

  4. Klicken Sie auf Abfrage ausführen.

Das folgende Beispiel zeigt einen Logeintrag für die Straggler-Erkennung.

  {
    ...
    "jsonPayload": {
      ...
      "@type": "type.googleapis.com/ml.aitelemetry.performancedebugging.output.NetworkStragglersOutput",
      "suspectedStragglersDetection": {
        "numNodes": 4,
        "nodes": [
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_1"
          },
          {
            "latencyMs": 9,
            "instanceId": "INSTANCE_ID_2"
          },
          {
            "instanceId": "INSTANCE_ID_3",
            "latencyMs": 4
          },
          {
            "instanceId": "INSTANCE_ID_4",
            "latencyMs": 0
          }
        ],
        "message": "Suspected stragglers detected."
      }
    },
    "resource": {
      "type": "project",
      "labels": {
        "project_id": "PROJECT_NUMBER"
      }
    },
    ...
    "severity": "INFO",
    "logName": "projects/PROJECT_ID/logs/compute.googleapis.com%2Fworkload_diagnostic",
    ...
  }

Der Logeintrag enthält diese Felder:

  • numNodes: Die Anzahl der im Projekt erkannten mutmaßlichen Nachzügler-Compute-Instanzen. Im Beispiel wurden vier mutmaßliche Nachzügler-Compute-Instanzen erkannt.
  • instanceId: Die ID einer Compute-Instanz, die als mutmaßlicher Nachzügler erkannt wurde.

Nächste Schritte