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 create utilizzando la capacità con 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à dei workload.

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 della rete tra blocchi e blocchi secondari

  • Efficienza dei workload di machine learning (ML)

  • Rilevamento degli elementi lenti

  • Rilevamento di workload che non rispondono

Per monitorare i cluster Cluster Director, consulta Monitora le prestazioni dei cluster con dashboard predefinite.

Prima di iniziare

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

Quando utilizzi la console Google Cloud per accedere ai servizi e alle API Google Cloud , 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 computing 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 computing devono utilizzare la serie di macchine A4X Max, A4X, A4, A3 Ultra o A3 Mega.
      • Tuttavia, il rilevamento dei ritardatari supporta anche le istanze di macchine virtuali (VM) che utilizzano la serie di macchine A3 Mega.

Per monitorare le metriche dei workload ML, devi configurare il monitoraggio per il tuo workload.

Limitazioni del rilevamento degli elementi lenti

Le metriche di rilevamento degli straggler presentano le seguenti limitazioni aggiuntive:

  • Per le serie di macchine supportate diverse da A3 Mega, il rilevamento dei ritardatari supporta solo le istanze di computing che consentono alla libreria Collective Communication Analyzer (CoMMA) di esportare la telemetria NCCL ai servizi Google Cloud . Per saperne di più, consulta la panoramica di CoMMA.
  • In genere, il rilevamento degli straggler richiede fino a 10 minuti per segnalare uno straggler.
  • A differenza delle altre metriche di questo documento, non puoi filtrare le metriche di rilevamento degli elementi lenti per i tuoi progetti in base a cluster, blocco, sottoblocco o istanza di computing. 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 workload che non rispondono supportano solo le istanze di computing che utilizzano la libreria Collective Communication Analyzer (CoMMA) per esportare la telemetria NCCL ai 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 workload di AI Hypercomputer, chiedi all'amministratore di concederti i seguenti ruoli IAM:

  • Per visualizzare le metriche in Cloud Monitoring: Monitoring Editor (roles/monitoring.editor) sul progetto
  • Per visualizzare i log di rilevamento degli straggler in Logging: Visualizzatore log (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 workload di AI Hypercomputer. Per vedere quali sono esattamente le autorizzazioni richieste, espandi la sezione Autorizzazioni obbligatorie:

Autorizzazioni obbligatorie

Per monitorare le metriche dei workload di 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, sono disponibili le seguenti metriche per il monitoraggio delle istanze di computing e dei cluster Slurm:

Per scoprire come visualizzare queste metriche, consulta Visualizza 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 Metriche diGoogle Cloud .

Metriche di salute 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 o se non è integra e deve essere riparata.
Stato NVSwitch instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra o A3 Mega Indica 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 L'integrità del cluster, del blocco, del sottoblocco e dell'host su cui sono in esecuzione le istanze di computing. Se questa metrica mostra che l'infrastruttura di un'istanza di computing non è in stato integro, 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, maggiore è la probabilità che l'istanza di computing si degradi. In questo caso, ti consigliamo di spostare il job in un'altra istanza di computing e, se riscontri problemi con l'istanza di computing, di segnalare l'host come difettoso.

Metriche sul rendimento 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 è impegnata nell'elaborazione di un workload.
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 computing con più GPU collegate, la metrica fornisce il consumo di energia 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) sulle GPU sono in uso.
Temperatura GPU instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra o A3 Mega La temperatura in gradi Celsius (℃) e in valori decimali delle singole GPU sull'host. Per le istanze di computing 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 della temperatura elevata. Per le istanze di computing con più GPU collegate, la metrica fornisce l'headroom termico separatamente per ogni GPU sull'host.

Metriche sul rendimento della rete GPU

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

Nome Tipo di metrica Serie di macchine supportate Descrizione
Modifiche al link dell'operatore instance/gpu/link_carrier_changes A4X, A4, A3 Ultra o A3 Mega La frequenza con cui l'operatore del link di rete cambia 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, necessario 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 tra blocchi secondari instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra o A3 Mega Il numero di byte di traffico di rete tra i blocchi secondari.
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 blocco secondario.
Velocità attiva NVLink instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra o A3 Mega La velocità attuale della porta del link di accesso, 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 degli 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à di switch e porte.
  • Valuta la capacità di larghezza di banda disponibile e la profondità della coda di buffer.
  • Diagnostica pacchetti scartati, errori, flap dell'interfaccia ed eventi di gestione della congestione.

Queste metriche utilizzano il tipo di risorsa monitorata compute.googleapis.com/NetworkSwitch 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 dei sensori sono organizzate nelle seguenti categorie:

Metriche di integrità e stato dello switch

Utilizza le metriche elencate in questa sezione per:

  • Verifica lo stato di attività delle porte dello switch.
  • Monitora l'utilizzo della CPU e della 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 chiave: 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 chiave: 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 chiave: 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 chiave: subblock_id, block_id, reservation_id, switch_type.
Cambia le metriche di capacità e coda

Per monitorare la capacità di rete di riferimento rispetto a quella utilizzabile e monitorare la profondità della coda di buffer e le interruzioni della coda 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à di larghezza di banda di riferimento potenziale totale di una connessione dello switch ToR al superblocco, in kilobit al secondo (kbit/s).
Etichette chiave: 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 superblocco, in kilobit al secondo (kbit/s). Questa metrica riflette le riduzioni della capacità causate da link con prestazioni ridotte o offline.
Etichette chiave: subblock_id, block_id, reservation_id, switch_type.
Profondità massima della coda in 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 chiave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Interruzioni della 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 della congestione della coda o dell'esaurimento del buffer.
Etichette chiave: port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Scarti nel buffer network_switch/in_buffer_discards A4X Max o A4X Il conteggio cumulativo dei pacchetti in entrata scartati in entrata a causa di un overflow del buffer.
Etichette chiave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Metriche relative a interruzioni, errori e controllo di flusso dello switch

Utilizza le metriche in questa sezione per diagnosticare i seguenti problemi, che possono causare blocchi dell'addestramento distribuito o timeout delle comunicazioni collettive (come i timeout del watchdog NCCL):

  • Pacchetti scartati, errori di trasmissione e interruzioni del collegamento fisico.
  • Errori di parole FEC (Forward Error Correction).
  • Eventi di gestione della congestione, come le pause del controllo di flusso basato sulla priorità (PFC) e i contrassegni di notifica esplicita di congestione (ECN).
Nome Tipo di metrica Serie di macchine supportate Descrizione
Flap dell'interfaccia network_switch/interface_flaps_count A4X Max o A4X Il conteggio cumulativo delle transizioni di stato del collegamento fisico (flap 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 parole FEC (Forward Error Correction). Utilizza l'etichetta booleana correctable (true o false) per distinguere tra errori correggibili e non correggibili.
Etichette chiave: port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
Pacchetti contrassegnati con 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 della soglia del buffer.
Etichette chiave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
Pacchetti PFC RX network_switch/pfc_rx_packets_count A4X Max o A4X Il numero cumulativo di frame di pausa del controllo di flusso basato sulla priorità (PFC) ricevuti sulla porta.
Nota: applicabile solo agli ambienti dedicati in cui è abilitato il PFC.
Etichette chiave: port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
Pacchetti PFC TX network_switch/pfc_tx_packets_count A4X Max o A4X Il conteggio cumulativo dei frame di pausa del controllo di flusso basato sulla priorità (PFC) trasmessi dalla porta per limitare il traffico in entrata.
Nota: applicabile solo agli ambienti dedicati in cui è abilitato il PFC.
Etichette chiave: 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 Quality of Service (QoS) trasmessi nella coda specificata.
Etichette chiave: 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 chiave: port_identifier, subblock_id, block_id, reservation_id, switch_type.
In errori 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 chiave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
In Discards network_switch/in_discards A4X Max o A4X Il conteggio cumulativo dei pacchetti in entrata validi che sono stati ignorati (ad esempio, a causa di spazio di buffer insufficiente).
Etichette chiave: 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 chiave: port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Scarti in uscita network_switch/out_discards A4X Max o A4X Il conteggio cumulativo dei pacchetti in uscita che sono stati scelti per essere scartati anche se non sono stati rilevati errori.
Etichette chiave: 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 chiave: 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 chiave: port_identifier, subblock_id, block_id, reservation_id, switch_type.

Metriche degli errori irreversibili della GPU

Per monitorare gli errori riscontrati dalle GPU che potrebbero forzare l'arresto delle istanze di computing 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 Se la rimappatura delle righe nelle DRAM della GPU non è riuscita a causa di uno dei seguenti problemi:
  • Un tentativo di rimappatura su un banco di memoria non è riuscito perché il banco di memoria ha già otto righe di errori non correggibili rimappate.
  • Un tentativo di rimappatura di una riga non è riuscito perché la riga era già stata rimappata.
  • Un tentativo di rimappatura non è riuscito perché sono state eseguite 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, impiegato dal workload per le attività di goodput. Queste attività sono attività principali e utili, come 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, impiegato dal workload per le attività di badput. Queste attività sono attività di overhead, come il caricamento o la pre-elaborazione dei dati per l'addestramento.

Metriche di rilevamento degli elementi lenti

Le metriche di rilevamento degli elementi lenti ti aiutano a notare e individuare gli elementi lenti sospetti. Gli elementi in ritardo sono errori single-point che non causano arresti anomali, ma che alla fine rallentano l'intero workload.

Per monitorare il rilevamento degli straggler 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 sospetti ritardatari solo quando altre metriche indicano che il workload sta riscontrando problemi.

Puoi anche visualizzare le metriche di rilevamento degli straggler 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 sospetti ritardi per VM specifiche. Utilizza questa query per verificare se sono presenti straggler sospetti per un workload 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 degli straggler per il tuo progetto. Utilizza questa query per verificare se il servizio di rilevamento degli straggler è in esecuzione quando non vengono rilevati straggler sospetti. (A causa delle limitazioni, non puoi filtrare i log senza ritardatari sospetti in base a VM specifiche). 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Le metriche di rilevamento degli straggler sono particolarmente utili per i workload di ML su larga scala per i seguenti motivi:

  • I workload di ML su larga scala sono molto sensibili ai ritardatari. I workload ML su larga scala utilizzano il computing sincrono e ampiamente distribuito. In altre parole, hanno molti componenti altamente interdipendenti che vengono eseguiti contemporaneamente. Questa architettura rende i workload ML su larga scala molto suscettibili a single point of failure come gli straggler.

  • Notare e individuare gli elementi lenti nei workload ML su larga scala è molto difficile. Per riferimento, tieni presente 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 peggioramento delle prestazioni senza arresti anomali. Sono molto difficili da individuare e sottoporre a debug.

    A causa della loro natura di errori lenti, gli straggler sono intrinsecamente difficili da notare e individuare, soprattutto nei workload sincroni su larga scala.

Metriche di rilevamento dei workload che non rispondono

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

  • Notare quando un intero workload si è bloccato (a volte definito blocco NCCL)
  • Capire perché il workload si è bloccato, ad esempio se è stato causato da un arresto anomalo del processo o da un blocco della rete

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

Nome Tipo di metrica Serie di macchine supportate Descrizione
Eventi di 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 reattivi rilevati, sotto forma di serie temporale.

Abilita il rilevamento dei workload che non rispondono

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

Per attivare manualmente la telemetria heartbeat per CoMMA, specifica le seguenti variabili di ambiente nel tuo 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.

Disattiva il rilevamento dei workload che non rispondono

Per disattivare il rilevamento dei workload che non rispondono, disattiva la telemetria heartbeat in CoMMA specificando la seguente variabile di ambiente nel tuo ambiente di addestramento:

NCCL_PROFILER_HEARTBEAT=false

Scopri 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ù rank, il che in genere indica un arresto anomalo 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 memoria esaurita (OOM), ad esempio dmesg, nei log di sistema.
  • Cerca guasti hardware o errori NVIDIA XID.
StalledRankIssue La telemetria heartbeat viene ancora ricevuta, ma i rank 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 gli impedisce di comunicare con altri, ad esempio un calcolo o un checkpointer.
MissingCommunicatorIssue Tutti i rank che appartengono a un comunicatore NCCL hanno smesso di fare progressi.
  • Il workload potrebbe essere stato interrotto o i suoi comunicatori NCCL potrebbero essere stati chiusi bruscamente. Se prevedi che un workload venga eseguito senza interruzioni 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 come segue:

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

Utilizza le dashboard predefinite

Puoi utilizzare le dashboard di Monitoring predefinite per AI Hypercomputer per visualizzare le metriche relative alle istanze di computing e ai 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, segui questi passaggi:

  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 una delle seguenti dashboard in base alle metriche che vuoi visualizzare:

    • Per monitorare l'integrità delle istanze di computing, le prestazioni della GPU e il rilevamento dei ritardatari, utilizza la dashboard Cluster Director Health Monitoring.

      Per saperne di più 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 Cluster Director Transmission Efficiency.

    • 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 la dashboard del playbook Playbook interattivo GCE - Rete di blocco di Cluster Director.

    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, segui questi passaggi:

  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 degli straggler 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 degli straggler.

  4. Fai clic su Esegui query.

Di seguito è riportato un esempio di voce di log di rilevamento degli straggler.

  {
    ...
    "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 ritardatarie rilevate nel progetto. Nell'esempio, sono state rilevate quattro istanze di computing sospette di essere in ritardo.
  • instanceId: l'ID di un'istanza di computing rilevata come sospetto straggler.

Passaggi successivi