Monitora le istanze Compute Engine e i cluster Slurm

Questo documento spiega come utilizzare le dashboard di Cloud Monitoring per monitorare le istanze A4X Max, A4X, A4, A3 Ultra e A3 Mega che hai creato utilizzando la capacità vincolata alla prenotazione. L'utilizzo di queste dashboard ti aiuta a identificare e risolvere i colli di bottiglia delle prestazioni nelle istanze Compute Engine autonome o nei cluster Slurm, riducendo al minimo i tempi di inattività nei tuoi carichi di lavoro.

Creando dashboard personalizzate o utilizzando dashboard di Monitoring predefinite, puoi monitorare quanto segue:

  • Integrità dell'istanza di computing

  • Prestazioni GPU

  • Efficienza della trasmissione di rete

  • Efficienza di rete tra blocchi e sottoblocchi

  • Efficienza del workload di machine learning (ML)

  • Rilevamento di elementi in ritardo

  • Rilevamento di workload che non rispondono

Per monitorare i cluster Cluster Director, vedi Monitorare le prestazioni del cluster con dashboard predefinite.

Prima di iniziare

Prima di monitorare il carico di lavoro, se non l'hai ancora fatto, completa i seguenti passaggi:

Quando utilizzi la console Google Cloud per accedere ai servizi Google Cloud e alle API, non devi configurare l'autenticazione.

Limitazioni

  • Le metriche in questo documento sono supportate solo per i workload eseguiti su istanze di computing che soddisfano tutti i seguenti criteri:

    • Le istanze di calcolo devono essere create come istanze Compute Engine autonome o come parte di un cluster Slurm.
    • Le istanze di computing devono essere state create utilizzando la capacità con prenotazione.
    • Le istanze di calcolo devono utilizzare le serie di macchine A4X Max, A4X, A4, A3 Ultra o A3 Mega.
      • Tuttavia, il rilevamento di ritardatari supporta anche le istanze di macchine virtuali (VM) che utilizzano la serie di macchine A3 Mega.

Le metriche in questo documento sono supportate solo per i workload eseguiti su istanze di computing che soddisfano tutti i seguenti criteri:

  • Le istanze di calcolo devono essere create come istanze Compute Engine autonome o come parte di un cluster Slurm.
  • Le istanze di computing devono essere state create utilizzando la capacità riservata.
  • Le istanze di calcolo devono utilizzare le serie di macchine A4X Max, A4X, A4, A3 Ultra o A3 Mega.

Per monitorare le metriche del carico di lavoro ML, devi configurare il monitoraggio per il tuo carico di lavoro.

Limitazioni del rilevamento di elementi in ritardo

Le metriche di rilevamento dei ritardatari presentano le seguenti limitazioni aggiuntive:

  • Per le serie di macchine supportate diverse da A3 Mega, il rilevamento di ritardatari supporta solo le istanze di calcolo che consentono alla libreria Collective Communication Analyzer (CoMMA) di esportare la telemetria NCCL nei servizi Google Cloud . Per saperne di più, consulta la panoramica di CoMMA.
  • In genere, il rilevamento di un ritardatario richiede fino a 10 minuti per segnalarlo.
  • A differenza delle altre metriche in questo documento, non puoi filtrare le metriche di rilevamento dei valori anomali per i tuoi progetti in base a cluster, blocco, sottoblocco o istanza di calcolo. Tuttavia, puoi filtrare le query per i log di rilevamento dei ritardatari in base all'ID di una o più istanze di computing sospettate di essere ritardatarie.

Limitazioni del rilevamento dei workload che non rispondono

Le metriche di rilevamento dei carichi di lavoro che non rispondono supportano solo le istanze di calcolo che utilizzano la libreria Collective Communication Analyzer (CoMMA) per esportare la telemetria NCCL nei servizi Google Cloud . Per saperne di più, consulta la panoramica di CoMMA.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per monitorare le metriche per i carichi di lavoro AI Hypercomputer, chiedi all'amministratore di concederti i seguenti ruoli IAM:

  • Per visualizzare le metriche in Cloud Monitoring: Editor Monitoring (roles/monitoring.editor) sul progetto
  • Per visualizzare i log di rilevamento dei ritardatari in Logging: Logs Viewer (roles/logging.viewer) sul progetto

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Questi ruoli predefiniti contengono le autorizzazioni necessarie per monitorare le metriche per i carichi di lavoro AI Hypercomputer. Per vedere quali sono esattamente le autorizzazioni richieste, espandi la sezione Autorizzazioni obbligatorie:

Autorizzazioni obbligatorie

Per monitorare le metriche per i carichi di lavoro AI Hypercomputer sono necessarie le seguenti autorizzazioni:

  • Per visualizzare le dashboard: monitoring.dashboards.get sul progetto
  • Per creare dashboard: monitoring.dashboards.create sul progetto
  • Per visualizzare le voci di log: logging.logEntries.list sul progetto

Potresti anche ottenere queste autorizzazioni con ruoli personalizzati o altri ruoli predefiniti.

Metriche disponibili

A seconda del caso d'uso, per il monitoraggio sono disponibili le seguenti metriche delle istanze di computing e dei cluster Slurm:

Per scoprire come visualizzare queste metriche, consulta Visualizzare le metriche in questo documento.

Metriche dell'infrastruttura

Per monitorare l'integrità, le prestazioni e le prestazioni di rete delle GPU collegate alle istanze di computing, puoi utilizzare le seguenti metriche:

Per una panoramica delle metriche disponibili in Compute Engine, consulta le metriche diGoogle Cloud .

Metriche di integrità della GPU

Per monitorare l'integrità delle GPU, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Stato della macchina machine/machine_status A4X Max, A4X, A4, A3 Ultra o A3 Mega Indica se la macchina utilizzata dall'istanza di computing è integra oppure non è integra e richiede una riparazione.
Stato NVSwitch instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra o A3 Mega Se uno switch NVLink su una GPU NVIDIA collegata a un'istanza di computing sta riscontrando problemi.
Integrità dell'infrastruttura VM instance/gpu/infra_health A4X, A4, A3 Ultra o A3 Mega Lo stato di integrità del cluster, del blocco, del blocco secondario e dell'host su cui sono in esecuzione le istanze di computing. Se questa metrica mostra che l'infrastruttura di un'istanza di calcolo non è integra, la metrica descrive anche il problema.
Punteggio di previsione degli errori della VM instance/gpu/failure_prediction_score A4X, A4, A3 Ultra o A3 Mega La probabilità che l'host su cui viene eseguita l'istanza di computing si degradi nelle prossime cinque ore. Il valore può essere compreso tra 0.0 e 1.0. Più il valore rimane vicino a 1.0 per un periodo di tempo costante, più è probabile che l'istanza di computing si degraderà. In questo caso, ti consigliamo di spostare il job su un'altra istanza di computing e, se riscontri problemi con l'istanza di computing, segnala il relativo host come difettoso.

Metriche sulle prestazioni della GPU

Per monitorare le prestazioni delle GPU, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Utilizzo del contesto accumulato instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra o A3 Mega Il tempo totale, in secondi, durante il quale la GPU è occupata a elaborare un carico di lavoro.
Consumo di energia GPU instance/gpu/power_consumption A4X Max, A4X, A4, A3 Ultra o A3 Mega La potenza in watt (W) e in valori decimali consumata dalle singole GPU sull'host. Per le istanze di calcolo con più GPU collegate, la metrica fornisce il consumo energetico separatamente per ogni GPU sull'host.
Utilizzo SM instance/gpu/sm_utilization A4X Max, A4X, A4, A3 Ultra o A3 Mega Un valore diverso da zero indica che i multiprocessori streaming (SM) delle GPU sono in uso attivo.
Temperatura GPU instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra o A3 Mega La temperatura in gradi Celsius (°C) e in valori decimali delle singole GPU sull'host. Per le istanze di calcolo con più GPU collegate, la metrica fornisce la temperatura separatamente per ogni GPU sull'host.
Margine termico GPU instance/gpu/tlimit A4X Max, A4X, A4, A3 Ultra o A3 Mega Il margine termico in gradi Celsius (℃) e in valori decimali che le singole GPU hanno prima di dover rallentare a causa dell'alta temperatura. Per le istanze di calcolo con più GPU collegate, la metrica fornisce il margine termico separatamente per ogni GPU sull'host.

Metriche delle prestazioni di rete della GPU

Per monitorare le prestazioni di rete delle GPU, utilizza le seguenti metriche. Per monitorare gli switch di rete ToR di backend, consulta Metriche switch ToR.

Nome Tipo di metrica Serie di macchine supportate Descrizione
Modifiche ai link degli operatori instance/gpu/link_carrier_changes A4X, A4, A3 Ultra o A3 Mega La frequenza con cui cambia il link di rete in un minuto.
RTT di rete instance/gpu/network_rtt A4X, A4, A3 Ultra o A3 Mega Il tempo di round trip, misurato in microsecondi, per il trasferimento dei dati di rete tra un'origine e una destinazione.
Traffico di rete tra blocchi instance/gpu/network/inter_block_tx A4X, A4, A3 Ultra o A3 Mega Il numero di byte di traffico di rete tra i blocchi.
Traffico di rete a livello di inter-sub-block instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra o A3 Mega Il numero di byte di traffico di rete tra i sottoblocchi.
Traffico di rete all'interno del blocco secondario instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra o A3 Mega Il numero di byte di traffico di rete all'interno di un singolo sottoblocco.
Velocità attiva NVLink instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra o A3 Mega La velocità della porta del link di accesso corrente, in GBps.
Byte throughput di ricezione instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra o A3 Mega Il numero di byte ricevuti dal traffico di rete.
Byte throughput di trasmissione instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra o A3 Mega Il numero di byte trasmessi al traffico di rete.

Metriche dello switch ToR

Per i cluster A4X Max e A4X, puoi monitorare la telemetria dello switch di rete ToR di backend per eseguire le seguenti operazioni durante l'addestramento ML distribuito:

  • Osserva l'integrità dello switch e della porta.
  • Valuta la capacità di larghezza di banda disponibile e le profondità della coda del buffer.
  • Diagnostica gli scarti di pacchetti, gli errori, i flap dell'interfaccia e gli eventi di gestione della congestione.

Queste metriche utilizzano il compute.googleapis.com/NetworkSwitch tipo di risorsa monitorata e il prefisso del tipo di metrica compute.googleapis.com/. In Esplora metriche, seleziona il tipo di risorsa NetworkSwitch (compute.googleapis.com/NetworkSwitch).

Le metriche di conversione sono organizzate nelle seguenti categorie:

Metriche di salute e stato dell'interruttore

Utilizza le metriche elencate in questa sezione per:

  • Verifica lo stato operativo delle porte dello switch.
  • Monitora l'utilizzo di CPU e memoria dello switch.
  • Controlla i tempi di avvio per rilevare riavvii imprevisti.
Nome Tipo di metrica Serie di macchine supportate Descrizione
Stato del trasferimento network_switch/port_status A4X Max o A4X Indica lo stato operativo dell'interfaccia fisica (porta) sullo switch di rete. Il valore della metrica è sempre 1 per l'aggregazione; lo stato effettivo è fornito nell'etichetta status (ad esempio UP o DOWN).
Etichette chiave: port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Utilizzo CPU network_switch/cpu_utilization A4X Max o A4X L'utilizzo della CPU dello switch di rete, misurato come frazione da 0.0 a 1.0.
Etichette delle chiavi:subblock_id, block_id, reservation_id, switch_type.
Memoria utilizzata network_switch/memory_used A4X Max o A4X La memoria utilizzata dallo switch di rete, in byte.
Etichette delle chiavi:subblock_id, block_id, reservation_id, switch_type.
Memoria totale network_switch/total_memory_bytes A4X Max o A4X La capacità di memoria totale dello switch di rete, in byte.
Etichette delle chiavi:subblock_id, block_id, reservation_id, switch_type.
Tempo di avvio network_switch/boot_time_in_ns A4X Max o A4X Il timestamp di avvio dello switch di rete, in nanosecondi dall'epoca di Unix.
Etichette delle chiavi:subblock_id, block_id, reservation_id, switch_type.
Metriche di capacità e coda

Per monitorare la capacità di rete di base rispetto a quella utilizzabile e monitorare la profondità delle code di buffer e le eliminazioni di code sullo switch, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Capacità di riferimento network_switch/baseline_capacity_kbps A4X Max o A4X La capacità totale potenziale della larghezza di banda di base di una connessione a uno switch ToR al superblock, in kilobit al secondo (kbit/s).
Etichette delle chiavi:subblock_id, block_id, reservation_id, switch_type.
Capacità effettiva network_switch/effective_capacity_kbps A4X Max o A4X La capacità operativa utilizzabile di una connessione dello switch ToR al superblock, in kilobit al secondo (kbit/s). Questa metrica riflette le riduzioni di capacità causate da link degradati o offline.
Etichette chiave: subblock_id, block_id, reservation_id, switch_type.
Profondità massima della coda di uscita network_switch/egress_max_queue_depth A4X Max o A4X La profondità massima della coda osservata durante il ciclo di misurazione più recente.
Etichette dei tasti: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Eliminazioni dalla coda in uscita network_switch/egress_queue_drops_count A4X Max o A4X Il conteggio cumulativo dei pacchetti eliminati dalle code in uscita a causa di congestione della coda o esaurimento del buffer.
Etichette dei tasti: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
In buffer discards network_switch/in_buffer_discards A4X Max o A4X Il conteggio cumulativo dei pacchetti in entrata eliminati in entrata a causa dell'overflow del buffer.
Etichette dei tasti: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Metriche relative a interruzioni, errori e controllo del flusso dello switch

Utilizza le metriche in questa sezione per diagnosticare i seguenti problemi, che possono causare interruzioni dell'addestramento distribuito o timeout della comunicazione collettiva (ad esempio timeout del watchdog NCCL):

  • Eliminazioni di pacchetti, errori di trasmissione e instabilità dei link fisici.
  • Errori di parola di correzione degli errori in avanti (FEC).
  • Eventi di gestione della congestione, come le pause del controllo del flusso basato sulla priorità (PFC) e i contrassegni di notifica esplicita della congestione (ECN).
Nome Tipo di metrica Serie di macchine supportate Descrizione
Alette dell'interfaccia network_switch/interface_flaps_count A4X Max o A4X Il conteggio cumulativo delle transizioni di stato del collegamento fisico (flaps tra UP e DOWN) sull'interfaccia della porta dello switch.
Etichette chiave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Errori di parole Fec network_switch/fec_word_error_count A4X Max o A4X Il conteggio cumulativo degli errori di parola di correzione degli errori in avanti (FEC). Utilizza l'etichetta booleana correctable (true o false) per distinguere tra errori correggibili e non correggibili.
Etichette dei tasti: port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
Pacchetti contrassegnati ECN network_switch/ecn_marked_packets_count A4X Max o A4X Il conteggio cumulativo dei pacchetti contrassegnati con bit di notifica esplicita di congestione (ECN) a causa del superamento delle soglie del buffer.
Etichette chiave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pfc rx packets network_switch/pfc_rx_packets_count A4X Max o A4X Il conteggio cumulativo dei frame di pausa del controllo del flusso basato sulla priorità (PFC) ricevuti sulla porta.
Nota:applicabile solo agli ambienti dedicati in cui è abilitato PFC.
Etichette dei tasti: port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
Pfc tx packets network_switch/pfc_tx_packets_count A4X Max o A4X Il conteggio cumulativo dei frame di pausa del controllo del flusso basato sulla priorità (PFC) trasmessi dalla porta per limitare il traffico in entrata.
Nota:applicabile solo agli ambienti dedicati in cui è abilitato PFC.
Etichette dei tasti: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Pacchetti tx QoS network_switch/qos_tx_packets A4X Max o A4X Il conteggio cumulativo dei pacchetti di qualità del servizio (QoS) trasmessi nella coda specificata.
Etichette dei tasti: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Conteggio pacchetti in entrata network_switch/in_packets_count A4X Max o A4X Il conteggio cumulativo dei pacchetti in entrata ricevuti sulla porta dello switch.
Etichette dei tasti:port_identifier, subblock_id, block_id, reservation_id, switch_type.
In errors network_switch/in_errors A4X Max o A4X Il conteggio cumulativo dei pacchetti in entrata ricevuti con errori che ne hanno impedito la consegna.
Etichette dei tasti: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
In Scarti network_switch/in_discards A4X Max o A4X Il conteggio cumulativo dei pacchetti in entrata validi che sono stati eliminati (ad esempio, a causa di spazio buffer insufficiente).
Etichette dei tasti:port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Errori in uscita network_switch/out_errors A4X Max o A4X Il conteggio cumulativo dei pacchetti in uscita che non sono stati trasmessi a causa di errori.
Etichette dei tasti: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Eliminazioni in uscita network_switch/out_discards A4X Max o A4X Il conteggio cumulativo dei pacchetti in uscita che sono stati scelti per essere eliminati anche se non sono stati rilevati errori.
Etichette dei tasti:port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Conteggio byte in entrata network_switch/in_bytes_count A4X Max o A4X Il conteggio cumulativo dei byte in entrata ricevuti sulla porta dello switch.
Etichette dei tasti:port_identifier, subblock_id, block_id, reservation_id, switch_type.
Conteggio byte in uscita network_switch/out_bytes_count A4X Max o A4X Il conteggio cumulativo dei byte in uscita trasmessi dalla porta dello switch.
Etichette dei tasti:port_identifier, subblock_id, block_id, reservation_id, switch_type.

Metriche relative agli errori irreversibili della GPU

Per monitorare gli errori riscontrati dalle GPU e che potrebbero forzare l'arresto delle istanze di calcolo o influire negativamente sulle loro prestazioni, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Errore di runtime NVLink instance/gpu/nvlink_runtime_error A4X Max o A4X Indica se si è verificato un errore di runtime NVLink.
Errori ECC della DRAM non correggibili instance/gpu/dram_uncorrectable_ecc_error_count A4X Max o A4X Il numero di codici di correzione degli errori (ECC) non correggibili in una memoria ad accesso casuale dinamica (DRAM) della GPU.
Conteggio di rimappatura di righe della DRAM non correggibile instance/gpu/dram_uncorrectable_row_remapping_count A4X Max o A4X Il numero di rimappature di righe da errori non correggibili nelle DRAM della GPU.
Rimappatura di righe della DRAM non correggibile non riuscita instance/gpu/dram_row_remapping_failed A4X Max o A4X Indica se la rimappatura di righe nelle DRAM della GPU non è riuscita a causa di uno dei seguenti problemi:
  • Un tentativo di rimappatura di una banca di memoria non è riuscito perché la banca di memoria ha già rimappato otto righe di errori non correggibili.
  • Un tentativo di rimappatura di una riga non è riuscito perché la riga era già rimappata.
  • Un tentativo di rimappatura non è riuscito perché si sono verificate 512 rimappature totali.
Errori PCIe non correggibili instance/gpu/pcie_fatal_error_count A4X Max o A4X Il numero di errori PCIe (Peripheral Component Interconnect Express) non correggibili.
Errori ECC della cache non correggibili instance/gpu/cache_uncorrectable_ecc_error_count A4X Max o A4X Il numero di ECC non correggibili nella memoria cache.

Metriche dei workload ML

Per monitorare la produttività, in particolare il goodput, dei tuoi workload ML, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Tempo produttivo workload/goodput_time A4X, A4, A3 Ultra o A3 Mega Il tempo, in secondi, che il workload dedica alle attività di goodput. Queste attività sono utili e fondamentali, ad esempio un passaggio in avanti o indietro durante l'addestramento del modello.
Tempo non produttivo workload/badput_time A4X, A4, A3 Ultra o A3 Mega Il tempo, in secondi, che il workload dedica alle attività di badput. Queste attività sono attività di overhead, come il caricamento o la preelaborazione dei dati per l'addestramento.

Metriche di rilevamento degli elementi in ritardo

Le metriche di rilevamento dei ritardatari ti aiutano a notare e individuare i presunti ritardatari. Gli elementi in ritardo sono errori non irreversibili che si verificano in un unico punto e che alla fine rallentano l'intero carico di lavoro.

Per monitorare il rilevamento di ritardatari per le tue VM, utilizza la seguente metrica:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Elementi in ritardo sospetti instance/gpu/straggler_status A4X, A4, A3 Ultra o A3 Mega Indica se una VM è sospettata di essere un ritardatario che influisce sulle prestazioni del workload. Ti consigliamo di intervenire sui presunti ritardatari solo quando altre metriche indicano che il carico di lavoro sta riscontrando problemi.

Puoi anche visualizzare le metriche di rilevamento dei ritardatari nelle voci di log per un'istanza A4X, A4, A3 Ultra o A3 Mega. Ad esempio, puoi utilizzare le seguenti query:

Descrizione Query
Log con ritardatari sospetti per VM specifiche. Utilizza questa query per verificare la presenza di eventuali ritardatari sospetti per un carico di lavoro specifico nel tuo progetto. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

Sostituisci INSTANCE_ID con l'ID di una VM. Per ogni VM aggiuntiva che vuoi specificare, aggiungi la seguente condizione alla query:

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Tutti i log del rilevamento di ritardatari per il tuo progetto. Utilizza questa query per verificare se il servizio di rilevamento dei ritardatari è in esecuzione quando non vengono rilevati ritardatari sospetti. (A causa delle limitazioni, non puoi filtrare i log senza sospetti ritardatari in base a VM specifiche.) 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Le metriche di rilevamento dei ritardatari sono particolarmente utili per i carichi di lavoro ML su larga scala per i seguenti motivi:

  • I workload ML su larga scala sono molto sensibili ai ritardatari. I carichi di lavoro di ML su larga scala utilizzano il computing sincrono e distribuito in modo massiccio. In altre parole, hanno molti componenti altamente interdipendenti che vengono eseguiti contemporaneamente. Questa architettura rende i workload di ML su larga scala molto suscettibili a errori di tipo single-point come i ritardatari.

  • Individuare e identificare i ritardatari nei workload ML su larga scala è molto difficile. Per riferimento, considera che esistono due tipi di single point of failure:

    • Errori di arresto: errori che causano l'arresto dell'intero sistema. Ad esempio, errori dell'host ed eventi di manutenzione. Sono relativamente semplici da rilevare e risolvere.

    • Errori lenti: errori che causano un grave degrado delle prestazioni senza arresti anomali. Sono molto difficili da individuare e correggere.

    A causa della loro natura di errore lento, i ritardatari sono intrinsecamente difficili da notare e individuare, soprattutto in carichi di lavoro sincroni su larga scala.

Metriche di rilevamento dei workload che non rispondono

Le metriche di rilevamento dei carichi di lavoro che non rispondono ti aiutano a:

  • Notare quando un intero carico di lavoro è bloccato (a volte indicato come blocco NCCL)
  • Comprendi perché il workload si è bloccato, ad esempio se è stato causato da un arresto anomalo del processo o da una rete bloccata

Per rilevare e diagnosticare i workload che non rispondono per le tue istanze di calcolo, utilizza le seguenti metriche:

Nome Tipo di metrica Serie di macchine supportate Descrizione
Eventi del workload che non risponde rilevati utilizzando la telemetria NCCL instance/gpu/nccl_hang A4X Max, A4X, A4 e A3 Ultra Il numero di eventi di workload non rispondenti rilevati, come serie temporale.

Abilita il rilevamento dei workload che non rispondono

Per attivare il rilevamento dei workload che non rispondono, devi abilitare CoMMA con la telemetria heartbeat, un segnale ping periodico che indica che un workload è in esecuzione. Per le versioni recenti di CoMMA, questa opzione è abilitata per impostazione predefinita. Tuttavia, se utilizzi la versione di CoMMA del bundle NICCL/gIB dalla versione 1.1.1, devi attivare manualmente la telemetria heartbeat. Per verificare quale versione del bundle NICCL/gIB stai utilizzando, consulta Controllare la versione di NCCL e gIB.

Per attivare manualmente la telemetria heartbeat per CoMMA, specifica le seguenti variabili di ambiente nell'ambiente di addestramento:

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Utilizza NCCL_PROFILER_HEARTBEAT per attivare o disattivare la telemetria heartbeat e NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL per specificare la frequenza della telemetria heartbeat. Per saperne di più, consulta Variabili di ambiente CoMMA.

Disattivare il rilevamento dei workload che non rispondono

Per disattivare il rilevamento dei carichi di lavoro che non rispondono, disattiva la telemetria heartbeat in CoMMA specificando la seguente variabile di ambiente nell'ambiente di addestramento:

NCCL_PROFILER_HEARTBEAT=false

Perché i workload non rispondono

Per capire perché un workload non risponde, controlla il valore dell'etichetta hang_reason completando i seguenti passaggi:

  1. Nella console Google Cloud , vai alla pagina  Esplora metriche:

    Vai a Esplora metriche

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

  2. Cerca la seguente metrica:

    compute.googleapis.com/instance/gpu/nccl_hang

  3. Utilizza la funzionalità Aggregazione e seleziona le seguenti etichette:

    • instance_id
    • hang_reason

La tabella seguente elenca i possibili valori dell'etichetta, il loro significato per i tuoi workload e i passaggi successivi consigliati.

Valore etichetta Descrizione Passaggi successivi consigliati
MissingHeartbeatIssue La telemetria heartbeat è stata interrotta per uno o più ranghi, il che in genere indica un arresto anomalo fatale del processo o del nodo.
  • Verifica se l'istanza è ancora raggiungibile.
  • Verifica se i processi del workload hanno subito un arresto anomalo.
  • Controlla la presenza di eventi di esaurimento della memoria (OOM) , ad esempio dmesg, nei log di sistema.
  • Cerca guasti hardware o errori NVIDIA XID.
StalledRankIssue I dati di telemetria heartbeat vengono ancora ricevuti, ma i ranghi non avanzano nelle operazioni NCCL.
  • Esamina i potenziali deadlock nelle operazioni a livello di app.
  • Verifica se il processo dell'applicazione è bloccato in un'operazione che impedisce la comunicazione con altri, ad esempio il calcolo o il punto di controllo.
MissingCommunicatorIssue Tutti i ranghi appartenenti a un comunicatore NCCL hanno smesso di fare progressi.
  • Il carico di lavoro potrebbe essere stato interrotto o i relativi comunicatori NCCL potrebbero essere stati chiusi bruscamente. Se prevedi che un workload venga eseguito ininterrottamente su questa istanza VM, controlla se il workload è stato interrotto o arrestato in modo anomalo.
NoHangIssue Il valore predefinito. Nessun problema rilevato.
  • Non è richiesta alcuna azione da parte tua.

Visualizza metriche

Per visualizzare le metriche per le istanze di computing e i cluster Slurm, utilizza le dashboard di Monitoring nel seguente modo:

Se riscontri problemi durante l'utilizzo di una dashboard, consulta la pagina Risolvere i problemi di prestazioni lente.

Utilizzare le dashboard predefinite

Puoi utilizzare le dashboard di monitoraggio predefinite per AI Hypercomputer per visualizzare le metriche per le istanze di computing e i cluster Slurm. Puoi anche creare una copia di una dashboard predefinita e modificarla in base alle tue esigenze.

Per utilizzare una dashboard predefinita per AI Hypercomputer:

  1. Nella console Google Cloud , vai alla pagina  Dashboard:

    Vai a Dashboard

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

  2. Nella colonna Nome, fai clic sul nome di uno dei seguenti dashboard in base alle metriche che vuoi visualizzare:

    • Per monitorare l'integrità delle istanze di computing, le prestazioni della GPU e il rilevamento di straggler, utilizza la dashboard Monitoraggio dell'integrità di Cluster Director.

      Per ulteriori informazioni su come utilizzare queste metriche per identificare e analizzare i problemi, utilizza anche la dashboard del playbook GCE Interactive Playbook - Cluster Director Health Monitoring.

    • Per monitorare l'efficienza della trasmissione di rete, utilizza la dashboard Efficienza della trasmissione di Cluster Director.

    • Per monitorare l'efficienza della rete tra blocchi e sottoblocchi, utilizza la dashboard Cluster Director Block Network.

      Per ulteriori informazioni su come utilizzare queste metriche per identificare e analizzare i problemi, utilizza anche il dashboard del playbook interattivo GCE - Cluster Director Block Network.

    Viene visualizzata la pagina dei dettagli della dashboard scelta. Puoi utilizzare il selettore dell'intervallo di tempo nella barra degli strumenti per modificare l'intervallo di tempo dei dati.

  3. (Facoltativo) Per creare una copia di una dashboard e personalizzarla in base alle tue esigenze, fai clic su Copia dashboard.

Crea dashboard personalizzate

Per creare una dashboard di Monitoring personalizzata:

  1. Scegli le metriche da monitorare. Se non l'hai ancora fatto, consulta la sezione Metriche disponibili in questo documento.

  2. Crea e gestisci dashboard personalizzate.

Visualizza i log di rilevamento degli elementi in ritardo

Per visualizzare i log di rilevamento dei ritardatari utilizzando Esplora log, completa i seguenti passaggi:

  1. Nella console Google Cloud , vai alla pagina Esplora log:

    Vai a Esplora log

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Logging.

    Per impostazione predefinita, la pagina esegue query su tutti i log del progetto. Fai clic su Interrompi query.

  2. Utilizza il selettore dell'intervallo di tempo nella barra degli strumenti per selezionare l'intervallo di tempo che vuoi analizzare.

  3. Nel riquadro Query, inserisci una query per i log di rilevamento dei ritardatari.

  4. Fai clic su Esegui query.

Di seguito è riportato un esempio di voce di log di rilevamento di un'attività in ritardo.

  {
    ...
    "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",
    ...
  }

La voce di log include i seguenti campi:

  • numNodes: Il numero di istanze di computing sospette di essere in ritardo rilevate nel progetto. Nell'esempio, sono state rilevate quattro istanze di calcolo ritardatarie sospette.
  • instanceId: l'ID di un'istanza di computing rilevata come sospetta ritardataria.

Passaggi successivi