Compute Engine-Instanzen und Slurm-Cluster überwachen

In diesem Dokument wird beschrieben, wie Sie Cloud Monitoring-Dashboards verwenden, um A4X Max-, A4X-, A4-, A3 Ultra- und A3 Mega-Instanzen zu ü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 Ausfallzeiten in Ihren Arbeitslasten minimieren.

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

  • Status von Compute-Instanzen

  • GPU-Leistung

  • Effizienz der Netzwerkübertragung

  • Netzwerkeffizienz zwischen Blöcken und Unterblöcken

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

  • Nachzüglererkennung

  • Erkennung von nicht reagierenden Arbeitslasten

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

Hinweis

Bevor Sie Ihre Arbeitslast überwachen, sollten Sie die folgenden Schritte ausführen, falls Sie dies noch nicht getan haben:

Wenn Sie über die Google Cloud Console auf Google Cloud Dienste und APIs 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.
    • Für die Compute-Instanzen muss die Maschinenserie A4X Max, A4X, A4, A3 Ultra oder A3 Mega verwendet werden.
      • Die Erkennung von Nachzüglern unterstützt jedoch auch VM-Instanzen, die die Maschinenserie A3 Mega verwenden.

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 reservierter Kapazität erstellt worden sein.
  • Für die Compute-Instanzen muss die Maschinenserie A4X Max, A4X, A4, A3 Ultra oder A3 Mega verwendet werden.

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

Einschränkungen bei der Erkennung von Nachzüglern

Für Messwerte zur Erkennung von Stragglern gelten die folgenden zusätzlichen Einschränkungen:

  • Bei unterstützten Maschinenserien, die nicht A3 Mega sind, wird die Erkennung von Nachzüglern nur für Compute-Instanzen unterstützt, bei denen die CoMMA-Bibliothek (Collective Communication Analyzer) NCCL-Telemetrie in Google Cloud -Dienste exportieren kann. Weitere Informationen finden Sie in der CoMMA-Übersicht.
  • Es dauert in der Regel bis zu 10 Minuten, bis ein Nachzügler erkannt wird.
  • Im Gegensatz zu den anderen Messwerten in diesem Dokument können Sie Messwerte zur Erkennung von Straggler-Aufgaben für Ihre Projekte nicht nach Cluster, Block, Unterblock oder Compute-Instanz filtern. Sie können Abfragen für Logs zur Erkennung von Straggler-Instanzen jedoch nach der ID einer oder mehrerer Compute-Instanzen filtern, die als Straggler infrage kommen.

Einschränkungen bei der Erkennung nicht reagierender Arbeitslasten

Messwerte zur Erkennung nicht reagierender Arbeitslasten werden nur für Compute-Instanzen unterstützt, die die CoMMA-Bibliothek (Collective Communication Analyzer) verwenden, um NCCL-Telemetrie 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:

  • So rufen Sie Messwerte in Cloud Monitoring auf: Monitoring-Bearbeiter (roles/monitoring.editor) für das Projekt
  • So rufen Sie Logs zur Erkennung von Nachzüglern in Logging auf: Logbetrachter (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 beobachten:

  • So rufen Sie Dashboards auf: 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 sind die folgenden Messwerte zum Monitoring Ihrer Compute-Instanzen und Slurm-Cluster verfügbar:

  • Informationen zum Überwachen der Integrität, Leistung und 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 Erkennung von Nachzüglern.

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 der verfügbaren Messwerte in Compute Engine finden Sie unter Google Cloud -Messwerte.

GPU-Messwerte

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 Gibt an, ob der Computer, auf dem die Compute-Instanz ausgeführt wird, fehlerfrei ist oder ob der Computer fehlerhaft ist und repariert werden muss.
NVSwitch-Status instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra oder A3 Mega Gibt an, ob ein NVLink-Switch auf einer NVIDIA-GPU, die an eine Compute-Instanz angehängt ist, Probleme hat.
VM-Infrastrukturzustand instance/gpu/infra_health A4X, A4, A3 Ultra oder A3 Mega Der Status des Clusters, Blocks, Unterblocks und Hosts, auf dem Ihre Compute-Instanzen ausgeführt werden. Wenn dieser Messwert angibt, dass die Infrastruktur einer Compute-Instanz fehlerhaft ist, wird das Problem auch im Messwert beschrieben.
Vorhersagewert für VM-Fehler instance/gpu/failure_prediction_score A4X, A4, A3 Ultra oder A3 Mega Die Wahrscheinlichkeit, dass die Leistung des Hosts, auf dem die Compute-Instanz ausgeführt wird, in den nächsten fünf Stunden nachlässt. Der Wert kann zwischen 0.0 und 1.0 liegen. Je näher der Wert über einen längeren Zeitraum an 1.0 bleibt, desto wahrscheinlicher ist es, dass die Compute-Instanz beeinträchtigt wird. In diesem Fall empfehlen wir, den Job auf eine andere Compute-Instanz zu verschieben und den Host als fehlerhaft zu melden, wenn Probleme mit der Compute-Instanz auftreten.

GPU-Leistungsmesswerte

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

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Kumulierte Kontextnutzung instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die Gesamtzeit in Sekunden, in der 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 liefert der Messwert den Stromverbrauch für jede GPU auf dem Host separat.
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 Grad Celsius (°C) und in Dezimalwerten der einzelnen 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 Grad Celsius (°C) und in Dezimalwerten, den einzelne GPUs haben, bevor sie aufgrund hoher Temperaturen verlangsamt werden müssen. Bei Compute-Instanzen mit mehreren angehängten GPUs gibt der Messwert den thermischen Headroom für jede GPU auf dem Host separat an.

Messwerte zur GPU-Netzwerkleistung

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

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Änderungen bei der Verknüpfung von Mobilfunkanbietern instance/gpu/link_carrier_changes A4X, A4, A3 Ultra oder A3 Mega Wie oft sich der Carrier des Netzwerk-Links pro Minute ändert.
Netzwerk-RTT instance/gpu/network_rtt A4X, A4, A3 Ultra oder A3 Mega Die Umlaufzeit in Mikrosekunden für die Übertragung von Netzwerkdaten zwischen einer Quelle und einem Ziel.
Netzwerktraffic 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 Unterblöcken instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte des Netzwerkverkehrs zwischen Unterblöcken.
Netzwerktraffic innerhalb eines Unterblocks instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der Byte des Netzwerkverkehrs in einem einzelnen Unterblock.
Aktive NVLink-Geschwindigkeit instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra oder A3 Mega Die aktuelle Portgeschwindigkeit der Zugriffsverbindung in Gbit/s.
Durchsatz-RX-Bytes instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der durch Netzwerkverkehr empfangenen Bytes.
Durchsatz-Tx-Bytes instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra oder A3 Mega Die Anzahl der für den Netzwerkverkehr übertragenen Byte.

Messwerte für ToR-Switches

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 Pufferwarteschlangentiefe bewerten.
  • Paketverwerfungen, Fehler, Schnittstellenflaps und Ereignisse zur Überlastungssteuerung diagnostizieren.

Bei diesen Messwerten wird der überwachte Ressourcentyp compute.googleapis.com/NetworkSwitch und das Messwerttyp-Präfix compute.googleapis.com/ verwendet. 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:

Messwerte für Systemzustand und ‑status wechseln

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

  • Überprüfen Sie den Betriebsstatus der Switch-Ports.
  • Überwachen Sie die CPU- und Arbeitsspeicherauslastung des Switches.
  • Prüfen Sie die Startzeiten, 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 Bruch zwischen 0.0 und 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 gesamte Speicherkapazitä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.
Kapazitäts- und Warteschlangenmesswerte wechseln

Verwenden Sie die folgenden Messwerte, um die Referenz- und die nutzbare Netzwerkkapazität zu verfolgen und die Pufferwarteschlangenlängen und Warteschlangenverluste 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 Baseline-Bandbreitenkapazität 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 gibt Kapazitätsreduzierungen aufgrund von beeinträchtigten oder offline geschalteten Links an.
Schlüssellabels:subblock_id, block_id, reservation_id, switch_type.
Maximale Warteschlangentiefe 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.
Schlüssellabels:port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Verluste 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 Überlastung der Warteschlange oder Puffererschöpfung aus ausgehenden Warteschlangen verworfen wurden.
Schlüssellabels:port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Im Zwischenspeicher verworfene Daten network_switch/in_buffer_discards A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die aufgrund von Pufferüberlauf am Eingang verworfen wurden.
Schlüssellabels:port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Messwerte für Switch-Paketverluste, ‑Fehler und ‑Ablaufsteuerung

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

  • Verworfene Pakete, Übertragungsfehler und physische Link-Flaps.
  • FEC-Wortfehler (Forward Error Correction).
  • Ereignisse zur Stauverwaltung, z. B. PFC-Pausen (Priority-based Flow Control) und ECN-Markierungen (Explicit Congestion Notification).
Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Schnittstellenabdeckungen network_switch/interface_flaps_count A4X Max oder A4X Die kumulative Anzahl der Statusübergänge des physischen Links (Flaps zwischen UP und DOWN) auf der Switchport-Schnittstelle.
Schlüssellabels:port_identifier, subblock_id, block_id, reservation_id, switch_type.
Fehler bei der FEC-Wortkorrektur network_switch/fec_word_error_count A4X Max oder A4X Die kumulative Anzahl von FEC-Wortfehlern (Forward Error Correction). Verwenden Sie das boolesche Label correctable (true oder false), um zwischen korrigierbaren und nicht korrigierbaren Fehlern zu unterscheiden.
Schlüssellabels: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) markiert wurden.
Schlüssellabels:port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pfc-Empfangspakete network_switch/pfc_rx_packets_count A4X Max oder A4X Die kumulative Anzahl der PFC-Pausen-Frames (Priority-based Flow Control), die am Port empfangen wurden.
Hinweis:Gilt nur für dedizierte Umgebungen, in denen PFC aktiviert ist.
Schlüssellabels:port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
Pfc-Transaktionspakete network_switch/pfc_tx_packets_count A4X Max oder A4X Die kumulative Anzahl von PFC-Pausen-Frames (Priority-based Flow Control), die über den Port gesendet werden, um eingehenden Traffic zu drosseln.
Hinweis:Gilt nur für dedizierte Umgebungen, in denen PFC aktiviert ist.
Schlüssellabels: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.
Schlüssellabels:port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Anzahl der Pakete network_switch/in_packets_count A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die am Switch-Port empfangen wurden.
Schlüssellabels:port_identifier, subblock_id, block_id, reservation_id, switch_type.
Fehler network_switch/in_errors A4X Max oder A4X Die kumulative Anzahl der eingehenden Pakete, die mit Fehlern empfangen wurden, die eine 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 gültiger eingehender Pakete, die verworfen wurden (z. B. aufgrund von fehlendem Pufferspeicher).
Schlüssellabels:port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Fehler bei der Ausgabe 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.
Ausgeschiedene 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 Byte network_switch/in_bytes_count A4X Max oder A4X Die kumulative Anzahl der eingehenden Bytes, die am Switch-Port empfangen wurden.
Schlüssellabels:port_identifier, subblock_id, block_id, reservation_id, switch_type.
Anzahl der ausgehenden Byte network_switch/out_bytes_count A4X Max oder A4X Die kumulative Anzahl der ausgehenden Bytes, die über den Switch-Port übertragen wurden.
Schlüssellabels: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 sich negativ auf ihre Leistung auswirken:

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 (Error-Correcting Codes, ECCs) in einem dynamischen Arbeitsspeicher (Dynamic Random Access Memory, DRAM) der GPU.
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 die Neuzuordnung einer Zeile in GPU-DRAMs aufgrund eines der folgenden Probleme fehlgeschlagen ist:
  • Ein Versuch, eine Speicherbank neu zuzuordnen, ist fehlgeschlagen, da in der Speicherbank bereits acht Zeilen mit nicht korrigierbaren Fehlern neu zugeordnet wurden.
  • Ein Versuch, eine Zeile neu zuzuordnen, ist fehlgeschlagen, weil die Zeile bereits neu zugeordnet wurde.
  • Ein Versuch, die Zuordnung neu vorzunehmen, ist fehlgeschlagen, weil insgesamt 512 Neuzuordnungen erfolgt sind.
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.

Messwerte für ML-Arbeitslasten

Verwenden Sie die folgenden Messwerte, um die Produktivität, insbesondere den Goodput, Ihrer ML-Arbeitslasten zu überwachen:

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 für Badput-Aktivitäten aufgewendet wird. 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 Ausreißern können Sie verdächtige Ausreißer erkennen und eingrenzen. Nachzügler sind einzelne, nicht abstürzende Fehler, die die gesamte Arbeitslast verlangsamen.

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

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Mutmaßliche Nachzügler instance/gpu/straggler_status A4X, A4, A3 Ultra oder A3 Mega Gibt an, ob eine VM als Straggler 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 die Messwerte zur Erkennung von Nachzüglern auch 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 vermuteten Nachzüglern für bestimmte VMs: Mit dieser Abfrage können Sie prüfen, ob es für eine bestimmte Arbeitslast in Ihrem Projekt verdächtige Nachzügler 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, der Abfrage die folgende Bedingung 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 vermuteten Nachzügler erkannt werden. Aufgrund der Einschränkungen können Sie die Logs nicht nach bestimmten VMs filtern, ohne dass verdächtige Straggler berücksichtigt werden. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Messwerte zur Erkennung von Nachzüglern sind aus folgenden Gründen besonders hilfreich für umfangreiche ML-Arbeitslasten:

  • Umfangreiche ML-Arbeitslasten sind sehr anfällig für Straggler. 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-Fehler wie Straggler.

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

    • 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.

    Da sie sich langsam verschlechtern, sind sie von Natur aus schwer zu erkennen und zu lokalisieren, insbesondere bei synchronen Arbeitslasten in großem Maßstab.

Messwerte zur Erkennung nicht reagierender Arbeitslasten

Mit Messwerten zur Erkennung nicht reagierender Arbeitslasten können Sie Folgendes tun:

  • Erkennen, wenn eine gesamte Arbeitslast ins Stocken geraten ist (manchmal auch als NCCL-Hänger bezeichnet)
  • Sie können nachvollziehen, warum die Arbeitslast ins Stocken geraten ist, z. B. ob dies durch einen Prozessabsturz oder ein überlastetes Netzwerk verursacht wurde.

Mit den folgenden Messwerten können Sie nicht reagierende Arbeitslasten für Ihre Compute-Instanzen erkennen und diagnostizieren:

Name Messwerttyp Unterstützte Maschinenserien Beschreibung
Ereignisse für nicht reagierende Arbeitslasten, die mithilfe von NCCL-Telemetrie erkannt wurden instance/gpu/nccl_hang A4X Max, A4X, A4 und A3 Ultra Die Anzahl der erkannten Ereignisse für nicht reagierende Arbeitslasten als Zeitreihe.

Erkennung nicht reagierender Arbeitslasten aktivieren

Damit die Erkennung nicht reagierender Arbeitslasten aktiviert werden kann, müssen Sie CoMMA mit Heartbeat-Telemetrie aktivieren. Dabei handelt es sich um ein regelmäßiges Pingsignal, das angibt, dass eine Arbeitslast ausgeführt wird. In den aktuellen Versionen von CoMMA ist diese Funktion standardmäßig aktiviert. Wenn Sie jedoch die Version von CoMMA aus Version 1.1.1 des NICCL/gIB-Bundles verwenden, müssen Sie die Heartbeat-Telemetrie manuell aktivieren. Informationen dazu, wie Sie die Version des NICCL/gIB-Bundles ermitteln, 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

Verwende NCCL_PROFILER_HEARTBEAT, um die Herzschlag-Telemetrie zu aktivieren oder zu deaktivieren, und NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL, um die Häufigkeit der Herzschlag-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, indem Sie die folgende Umgebungsvariable in Ihrer Trainingsumgebung angeben:

NCCL_PROFILER_HEARTBEAT=false

Gründe für das Nichtreagieren von 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 das Feature 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, die Bedeutung dieser Werte für Ihre Arbeitslasten und empfohlene nächste Schritte aufgeführt.

Labelwert Beschreibung Empfehlungen
MissingHeartbeatIssue Die Heartbeat-Telemetrie wurde für mindestens einen Rang beendet. Das deutet in der Regel auf einen schwerwiegenden Prozess- oder Knotenabsturz hin.
  • Prüfen Sie, ob die Instanz noch erreichbar ist.
  • Prüfen Sie, ob Arbeitslastprozesse abgestürzt sind.
  • Prüfen Sie die Systemlogs auf Ereignisse vom Typ „Out of Memory“ (OOM), z. B. dmesg.
  • Suchen Sie nach Hardwarefehlern oder NVIDIA XID-Fehlern.
StalledRankIssue Es werden weiterhin Heartbeat-Telemetriedaten empfangen, aber die Ränge werden bei NCCL-Vorgängen nicht aktualisiert.
  • Untersuchen Sie potenzielle Deadlocks bei Vorgängen auf App-Ebene.
  • Prüfen Sie, ob der Anwendungsprozess in einem Vorgang steckt, der die Kommunikation mit anderen verhindert, z. B. bei der Berechnung oder beim Checkpointer.
MissingCommunicatorIssue Alle Ranks, die zu einem NCCL-Communicator gehören, haben keine Fortschritte mehr gemacht.
  • 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 heruntergefahren wurde.
NoHangIssue Der Standardwert. Es wurden keine Probleme festgestellt.
  • Sie müssen nichts weiter tun.

Messwerte aufrufen

So rufen Sie Messwerte für Ihre Compute-Instanzen und Slurm-Cluster auf: Verwenden Sie dazu Monitoring-Dashboards wie folgt:

Wenn bei der Verwendung eines Dashboards Probleme auftreten, lesen Sie den Abschnitt Probleme mit der Leistung beheben.

Vordefinierte Dashboards verwenden

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

So verwenden Sie ein vorgefertigtes 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 aufrufen möchten:

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

      Weitere Informationen zur Verwendung dieser Messwerte zum Identifizieren und Analysieren von Problemen finden Sie auch im Playbook-Dashboard GCE Interactive Playbook – Cluster Director Health Monitoring.

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

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

      Weitere Informationen zur Verwendung dieser Messwerte zum Identifizieren und Analysieren von Problemen finden Sie auch im GCE Interactive Playbook – Cluster Director Block Network-Dashboard.

    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 Messwerte aus, die überwacht werden sollen. Falls noch nicht geschehen, lesen Sie den Abschnitt Verfügbare Messwerte in diesem Dokument.

  2. Benutzerdefinierte Dashboards erstellen und verwalten

Logs zur Erkennung von Nachzüglern ansehen

So rufen Sie Logs zur Erkennung von Nachzüglern mit dem Log-Explorer auf:

  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.

    Standardmäßig werden auf der Seite 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 Protokolle zur Erkennung von Straggler-Ereignissen ein.

  4. Klicken Sie auf Abfrage ausführen.

Das folgende Beispiel zeigt einen Logeintrag zur Erkennung von Nachzüglern.

  {
    ...
    "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 mutmaßlichen Straggler-Compute-Instanzen, die im Projekt erkannt wurden. Im Beispiel wurden vier mutmaßliche Nachzügler-Compute-Instanzen erkannt.
  • instanceId: Die ID einer Compute-Instanz, die als mutmaßlicher Straggler erkannt wurde.

Nächste Schritte