Surveiller les instances Compute Engine et les clusters Slurm

Ce document explique comment utiliser les tableaux de bord Cloud Monitoring pour surveiller les instances A4X Max, A4X, A4, A3 Ultra et A3 Mega que vous avez créées à l'aide de la capacité liée à une réservation. Ces tableaux de bord vous aident à identifier et à résoudre les goulots d'étranglement des performances dans vos instances Compute Engine autonomes ou vos clusters Slurm, ce qui réduit les temps d'arrêt de vos charges de travail.

En créant des tableaux de bord personnalisés ou en utilisant des tableaux de bord Monitoring prédéfinis, vous pouvez surveiller les éléments suivants :

  • État de l'instance de calcul

  • Performances du GPU

  • Efficacité de la transmission réseau

  • Efficacité du réseau entre les blocs et les sous-blocs

  • Efficacité des charges de travail de machine learning (ML)

  • Détection des retardataires

  • Détection des charges de travail qui ne répondent pas

Pour surveiller les clusters Cluster Director, consultez Surveiller les performances des clusters avec des tableaux de bord prédéfinis.

Avant de commencer

Avant de surveiller votre charge de travail, si vous ne l'avez pas déjà fait, procédez comme suit :

Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud , vous n'avez pas besoin de configurer l'authentification.

Limites

  • Les métriques de ce document ne sont compatibles qu'avec les charges de travail qui s'exécutent sur des instances de calcul répondant à tous les critères suivants :

    • Les instances de calcul doivent être créées en tant qu'instances Compute Engine autonomes ou dans le cadre d'un cluster Slurm.
    • Les instances de calcul doivent avoir été créées à l'aide d'une capacité liée à une réservation.
    • Les instances de calcul doivent utiliser la série de machines A4X Max, A4X, A4, A3 Ultra ou A3 Mega.
      • Toutefois, la détection des traînards est également compatible avec les instances de machine virtuelle (VM) qui utilisent la série de machines A3 Mega.

Pour surveiller les métriques des charges de travail de ML, vous devez configurer la surveillance de votre charge de travail.

Limites de la détection des retardataires

Les métriques de détection des traînards présentent les limites supplémentaires suivantes :

  • Pour les séries de machines compatibles autres que A3 Mega, la détection des traînards n'est compatible qu'avec les instances de calcul qui permettent à la bibliothèque Collective Communication Analyzer (CoMMA) d'exporter la télémétrie NCCL vers les services Google Cloud . Pour en savoir plus, consultez la présentation de CoMMA.
  • La détection des traînards prend généralement jusqu'à 10 minutes pour signaler un traînard.
  • Contrairement aux autres métriques de ce document, vous ne pouvez pas filtrer les métriques de détection des traînards pour vos projets par cluster, bloc, sous-bloc ou instance de calcul. Toutefois, vous pouvez filtrer les requêtes pour les journaux de détection des traînards par l'ID d'une ou de plusieurs instances de calcul suspectées d'être des traînards.

Limites de la détection des charges de travail qui ne répondent pas

Les métriques de détection des charges de travail qui ne répondent pas ne sont compatibles qu'avec les instances de calcul qui utilisent la bibliothèque Collective Communication Analyzer (CoMMA) pour exporter la télémétrie NCCL vers les services Google Cloud . Pour en savoir plus, consultez la présentation de CoMMA.

Rôles requis

Pour obtenir les autorisations nécessaires pour surveiller les métriques des charges de travail AI Hypercomputer, demandez à votre administrateur de vous accorder les rôles IAM suivants :

  • To view metrics in Cloud Monitoring: Monitoring Editor (roles/monitoring.editor) on the project
  • Pour afficher les journaux de détection des traînards dans Logging : Lecteur de journaux (roles/logging.viewer) sur le projet

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour surveiller les métriques des charges de travail AI Hypercomputer. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour surveiller les métriques des charges de travail AI Hypercomputer :

  • Pour afficher les tableaux de bord : monitoring.dashboards.get sur le projet
  • Pour créer des tableaux de bord : monitoring.dashboards.create sur le projet
  • Pour afficher les entrées de journal : logging.logEntries.list sur le projet

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Métriques disponibles

En fonction de votre cas d'utilisation, les métriques suivantes sont disponibles pour surveiller vos instances de calcul et vos clusters Slurm :

Pour savoir comment afficher ces métriques, consultez la section Visualiser les métriques de ce document.

Métriques de l'infrastructure

Pour surveiller l'état, les performances et les performances réseau des GPU associés à vos instances de calcul, vous pouvez utiliser les métriques suivantes :

Pour obtenir un aperçu des métriques disponibles dans Compute Engine, consultez MétriquesGoogle Cloud .

Indicateurs de santé du GPU

Pour surveiller l'état de vos GPU, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
État de la machine machine/machine_status A4X Max, A4X, A4, A3 Ultra ou A3 Mega Indique si la machine utilisée par l'instance de calcul est opérationnelle ou non, et si elle nécessite une réparation.
État NVSwitch instance/gpu/nvswitch_status A4X Max, A4X, A4, A3 Ultra ou A3 Mega Indique si un commutateur NVLink sur un GPU NVIDIA associé à une instance de calcul rencontre des problèmes.
État de l'infrastructure de VM instance/gpu/infra_health A4X, A4, A3 Ultra ou A3 Mega L'état du cluster, du bloc, du sous-bloc et de l'hôte sur lesquels vos instances de calcul sont exécutées. Si cette métrique indique que l'infrastructure d'une instance de calcul n'est pas opérationnelle, elle décrit également le problème.
Score de prédiction des pannes de VM instance/gpu/failure_prediction_score A4X, A4, A3 Ultra ou A3 Mega Probabilité que l'hôte sur lequel l'instance de calcul s'exécute se dégrade au cours des cinq prochaines heures. Cette valeur peut être comprise entre 0.0 et 1.0. Plus la valeur reste proche de 1.0 pendant une période prolongée, plus l'instance de calcul risque de se dégrader. Dans ce cas, nous vous recommandons de déplacer le job vers une autre instance de calcul et, si vous rencontrez des problèmes avec l'instance de calcul, de signaler son hôte comme défectueux.

Métriques de performances des GPU

Pour surveiller les performances de vos GPU, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Utilisation cumulée du contexte instance/gpu/accumulated_context_utilization_seconds A4X Max, A4X, A4, A3 Ultra ou A3 Mega Durée totale, en secondes, pendant laquelle le GPU est occupé à traiter une charge de travail.
Consommation d'énergie du GPU instance/gpu/power_consumption A4X Max, A4X, A4, A3 Ultra ou A3 Mega Puissance en watts (W) et en valeurs décimales consommée sur les GPU individuels de l'hôte. Pour les instances de calcul auxquelles plusieurs GPU sont associés, la métrique fournit la consommation d'énergie séparément pour chaque GPU de l'hôte.
Utilisation du multiprocesseur de flux instance/gpu/sm_utilization A4X Max, A4X, A4, A3 Ultra ou A3 Mega Une valeur non nulle indique que les multiprocesseurs de flux (SM) de vos GPU sont activement utilisés.
Vitesse de GPU instance/gpu/temperature A4X Max, A4X, A4, A3 Ultra ou A3 Mega Température en degrés Celsius (℃) et en valeurs décimales des GPU individuels sur l'hôte. Pour les instances de calcul auxquelles plusieurs GPU sont associés, la métrique fournit la température séparément pour chaque GPU de l'hôte.
Marge thermique du GPU instance/gpu/tlimit A4X Max, A4X, A4, A3 Ultra ou A3 Mega Marge thermique en degrés Celsius (℃) et en valeurs décimales dont disposent les GPU individuels avant de devoir ralentir en raison d'une température élevée. Pour les instances de calcul auxquelles plusieurs GPU sont associés, la métrique fournit la marge thermique séparément pour chaque GPU de l'hôte.

Métriques de performances du réseau de GPU

Pour surveiller les performances réseau de vos GPU, utilisez les métriques suivantes. Pour surveiller les commutateurs réseau ToR de backend, consultez Métriques des commutateurs ToR.

Nom Type de métrique Séries de machines compatibles Description
Modifications de l'association de l'opérateur instance/gpu/link_carrier_changes A4X, A4, A3 Ultra ou A3 Mega Fréquence à laquelle l'opérateur de liaison réseau change en une minute.
RTT réseau instance/gpu/network_rtt A4X, A4, A3 Ultra ou A3 Mega Délai aller-retour, mesuré en microsecondes, pour que les données réseau transitent entre une source et une destination.
Trafic réseau entre les blocs instance/gpu/network/inter_block_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau entre les blocs.
Trafic réseau entre les sous-blocs instance/gpu/network/inter_subblock_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau entre les sous-blocs.
Trafic réseau au niveau intra-sous-bloc instance/gpu/network/intra_subblock_tx A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets de trafic réseau dans un seul sous-bloc.
Vitesse active NVLink instance/gpu/nvlink_active_speed A4X Max, A4X, A4, A3 Ultra ou A3 Mega Vitesse actuelle du port de liaison d'accès, en Gbit/s.
Débit de réception en octets instance/gpu/throughput_rx_bytes A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets reçus du trafic réseau.
Débit de transmission en octets instance/gpu/throughput_tx_bytes A4X, A4, A3 Ultra ou A3 Mega Nombre d'octets transmis au trafic réseau.

Métriques des commutateurs ToR

Pour les clusters A4X Max et A4X, vous pouvez surveiller la télémétrie du commutateur réseau ToR de backend pour effectuer les opérations suivantes pendant l'entraînement de ML distribué :

  • Surveillez l'état des commutateurs et des ports.
  • Évaluez la capacité de bande passante disponible et la profondeur de la file d'attente de tampon.
  • Diagnostiquez les rejets de paquets, les erreurs, les instabilités d'interface et les événements de gestion de la congestion.

Ces métriques utilisent le type de ressource surveillée compute.googleapis.com/NetworkSwitch et le préfixe de type de métrique compute.googleapis.com/. Dans l'explorateur de métriques, sélectionnez le type de ressource NetworkSwitch (compute.googleapis.com/NetworkSwitch).

Les métriques de commutateur sont organisées dans les catégories suivantes :

Métriques d'état et de santé du commutateur

Utilisez les métriques listées dans cette section pour :

  • Vérifier l'état opérationnel des ports de commutateur.
  • Surveillez l'utilisation du processeur et de la mémoire du commutateur.
  • Vérifiez les heures de démarrage pour détecter les redémarrages inattendus.
Nom Type de métrique Séries de machines compatibles Description
État du transfert network_switch/port_status A4X Max ou A4X Indique l'état opérationnel de l'interface physique (port) sur le commutateur réseau. La valeur de la métrique est toujours 1 pour l'agrégation. L'état réel est fourni dans l'étiquette status (par exemple, UP ou DOWN).
Étiquettes de clé : port_identifier, status, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Utilisation du processeur network_switch/cpu_utilization A4X Max ou A4X Utilisation du processeur du commutateur réseau, mesurée sous forme de fraction de 0.0 à 1.0.
Libellés des touches : subblock_id, block_id, reservation_id, switch_type.
Memory used network_switch/memory_used A4X Max ou A4X Mémoire utilisée par le commutateur réseau, en octets.
Libellés des touches : subblock_id, block_id, reservation_id, switch_type.
Mémoire totale network_switch/total_memory_bytes A4X Max ou A4X Capacité totale de la mémoire du commutateur réseau, en octets.
Libellés des touches : subblock_id, block_id, reservation_id, switch_type.
Temps de démarrage network_switch/boot_time_in_ns A4X Max ou A4X Code temporel de démarrage du commutateur réseau, en nanosecondes depuis l'epoch Unix.
Libellés des touches : subblock_id, block_id, reservation_id, switch_type.
Métriques de capacité et de file d'attente du commutateur

Pour suivre la capacité réseau de référence par rapport à la capacité réseau utilisable, et surveiller la profondeur de la file d'attente de tampon et les pertes de file d'attente sur le commutateur, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Capacité de référence network_switch/baseline_capacity_kbps A4X Max ou A4X Capacité totale de bande passante de référence potentielle d'une connexion de commutateur ToR au superbloc, en kilobits par seconde (kbit/s).
Libellés des touches : subblock_id, block_id, reservation_id, switch_type.
Capacité effective network_switch/effective_capacity_kbps A4X Max ou A4X Capacité opérationnelle utilisable d'une connexion de commutateur ToR au superbloc, en kilobits par seconde (kbit/s). Cette métrique reflète les réductions de capacité causées par des liaisons dégradées ou hors connexion.
Libellés des touches : subblock_id, block_id, reservation_id, switch_type.
Profondeur maximale de la file d'attente de sortie network_switch/egress_max_queue_depth A4X Max ou A4X Profondeur maximale de la file d'attente observée au cours du cycle de mesure le plus récent.
Libellés de clé : port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Suppression de la file d'attente de sortie network_switch/egress_queue_drops_count A4X Max ou A4X Nombre cumulé de paquets supprimés des files d'attente de sortie en raison d'un encombrement de la file d'attente ou d'un épuisement de la mémoire tampon.
Libellés de clé : port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Rejets dans le tampon network_switch/in_buffer_discards A4X Max ou A4X Nombre cumulé de paquets entrants supprimés à l'entrée en raison d'un dépassement de la mémoire tampon.
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Métriques sur les pertes, les erreurs et le contrôle de flux des commutateurs

Utilisez les métriques de cette section pour diagnostiquer les problèmes suivants, qui peuvent entraîner des blocages de l'entraînement distribué ou des délais d'inactivité de communication collective (tels que les délais d'inactivité du watchdog NCCL) :

  • Paquets supprimés, erreurs de transmission et instabilité de la liaison physique.
  • Erreurs de mots de correction d'erreur directe (FEC).
  • Événements de gestion de la congestion, tels que les pauses de contrôle de flux basé sur la priorité (PFC) et les marquages de notification explicite de congestion (ECN).
Nom Type de métrique Séries de machines compatibles Description
Flaps d'interface network_switch/interface_flaps_count A4X Max ou A4X Nombre cumulé de transitions d'état de liaison physique (battements entre UP et DOWN) sur l'interface du port du commutateur.
Libellés des touches : port_identifier, subblock_id, block_id, reservation_id, switch_type.
Erreurs de mots FEC network_switch/fec_word_error_count A4X Max ou A4X Nombre cumulé d'erreurs de mots de correction d'erreur sans voie de retour (FEC). Utilisez l'étiquette booléenne correctable (true ou false) pour distinguer les erreurs corrigibles des erreurs non corrigibles.
Libellés des touches : port_identifier, correctable, subblock_id, block_id, reservation_id, switch_type.
Paquets marqués ECN network_switch/ecn_marked_packets_count A4X Max ou A4X Nombre cumulé de paquets marqués avec des bits de notification explicite de congestion (ECN) en raison du dépassement du seuil de la mémoire tampon.
Libellés des touches : port_identifier, subblock_id, block_id, reservation_id, switch_type.
Paquets PFC rx network_switch/pfc_rx_packets_count A4X Max ou A4X Nombre cumulé de trames de pause PFC (Priority-based Flow Control) reçues sur le port.
Remarque : Ne s'applique qu'aux environnements dédiés où le contrôle de flux basé sur la priorité est activé.
Libellés de clé : port_identifier, priority_index, subblock_id, block_id, reservation_id, switch_type.
Paquets TX PFC network_switch/pfc_tx_packets_count A4X Max ou A4X Nombre cumulé de trames de pause PFC (Priority-based Flow Control) transmises hors du port pour limiter le trafic entrant.
Remarque : Ne s'applique qu'aux environnements dédiés où le PFC est activé.
Libellés de clé : port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Paquets QoS tx network_switch/qos_tx_packets A4X Max ou A4X Nombre cumulé de paquets de qualité de service (QoS) transmis sur la file d'attente spécifiée.
Libellés des touches : port_identifier, queue_name, subblock_id, block_id, reservation_id, switch_type.
Nombre de paquets entrants network_switch/in_packets_count A4X Max ou A4X Nombre cumulé de paquets entrants reçus sur le port du commutateur.
Libellés des touches : port_identifier, subblock_id, block_id, reservation_id, switch_type.
En cas d'erreur network_switch/in_errors A4X Max ou A4X Nombre cumulé de paquets entrants reçus avec des erreurs qui ont empêché leur distribution.
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Dans les éléments supprimés network_switch/in_discards A4X Max ou A4X Nombre cumulé de paquets entrants valides qui ont été supprimés (par exemple, en raison d'un manque d'espace tampon).
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Erreurs sortantes network_switch/out_errors A4X Max ou A4X Nombre cumulé de paquets sortants qui n'ont pas pu être transmis en raison d'erreurs.
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Rejets sortants network_switch/out_discards A4X Max ou A4X Nombre cumulé de paquets sortants qui ont été supprimés, même si aucune erreur n'a été détectée.
Libellés de clé : port_identifier, peer_target_identifier, peer_port_identifier, subblock_id, block_id, reservation_id, switch_type.
Nombre d'octets entrants network_switch/in_bytes_count A4X Max ou A4X Nombre cumulé d'octets entrants reçus sur le port du commutateur.
Libellés des touches : port_identifier, subblock_id, block_id, reservation_id, switch_type.
Nombre d'octets sortants network_switch/out_bytes_count A4X Max ou A4X Nombre cumulé d'octets sortants transmis depuis le port du commutateur.
Libellés des touches : port_identifier, subblock_id, block_id, reservation_id, switch_type.

Métriques d'erreurs fatales du GPU

Pour surveiller les erreurs que rencontrent vos GPU et qui peuvent forcer l'arrêt de vos instances de calcul ou avoir un impact négatif sur leurs performances, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Erreur d'exécution NVLink instance/gpu/nvlink_runtime_error A4X Max ou A4X Indique si une erreur d'exécution NVLink s'est produite.
Erreurs ECC DRAM non corrigibles instance/gpu/dram_uncorrectable_ecc_error_count A4X Max ou A4X Nombre de codes de correction d'erreur (ECC) non corrigibles dans une mémoire vive dynamique (DRAM) de GPU.
Nombre de remappages de lignes DRAM non corrigibles instance/gpu/dram_uncorrectable_row_remapping_count A4X Max ou A4X Nombre de remappages de lignes à partir d'erreurs non corrigibles dans les DRAM du GPU.
Échec du remappage de la ligne DRAM non corrigible instance/gpu/dram_row_remapping_failed A4X Max ou A4X Indique si un remappage de ligne dans les DRAM du GPU a échoué pour l'une des raisons suivantes :
  • Une tentative de remappage sur une banque de mémoire a échoué, car la banque de mémoire comporte déjà huit lignes d'erreur non corrigibles remappées.
  • Une tentative de remappage sur une ligne a échoué, car la ligne avait déjà été remappée.
  • Une tentative de remappage a échoué, car 512 remappages ont déjà eu lieu.
Erreurs PCIe non corrigibles instance/gpu/pcie_fatal_error_count A4X Max ou A4X Nombre d'erreurs PCIe (Peripheral Component Interconnect Express) non corrigibles.
Erreurs ECC de cache non corrigibles instance/gpu/cache_uncorrectable_ecc_error_count A4X Max ou A4X Nombre d'ECC non corrigibles dans la mémoire cache.

Métriques de charge de travail de ML

Pour surveiller la productivité (en particulier le goodput) de vos charges de travail de ML, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Temps productif workload/goodput_time A4X, A4, A3 Ultra ou A3 Mega Temps, en secondes, que la charge de travail consacre aux activités de débit utile. Ces activités sont des tâches essentielles et utiles, telles qu'une passe avant ou arrière pendant l'entraînement du modèle.
Temps non productif workload/badput_time A4X, A4, A3 Ultra ou A3 Mega Temps, en secondes, que la charge de travail consacre aux activités de badput. Ces activités sont des tâches de surcharge, telles que le chargement ou le prétraitement des données pour l'entraînement.

Métriques de détection des retardataires

Les métriques de détection des traînards vous aident à repérer et à identifier les traînards potentiels. Les retardataires sont des défaillances ponctuelles qui ne provoquent pas de plantage, mais qui finissent par ralentir l'ensemble de la charge de travail.

Pour surveiller la détection des traînards pour vos VM, utilisez la métrique suivante :

Nom Type de métrique Séries de machines compatibles Description
Retardataires suspectés instance/gpu/straggler_status A4X, A4, A3 Ultra ou A3 Mega Indique si une VM est suspectée d'être un traînard qui affecte les performances de la charge de travail. Nous vous recommandons de n'agir sur les traînards suspectés que lorsque d'autres métriques indiquent que la charge de travail rencontre des problèmes.

Vous pouvez également afficher les métriques de détection des traînards dans les entrées de journal d'une instance A4X, A4, A3 Ultra ou A3 Mega. Par exemple, vous pouvez utiliser les requêtes suivantes :

Description Requête
Journaux avec des traînards suspectés pour des VM spécifiques. Utilisez cette requête pour vérifier s'il existe des retardataires suspectés pour une charge de travail spécifique dans votre projet. 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic" AND jsonPayload.suspectedStragglersDetection.numNodes > 0 AND jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"

Remplacez INSTANCE_ID par l'ID d'une VM. Pour chaque VM supplémentaire que vous souhaitez spécifier, ajoutez la condition suivante à la requête :

    OR jsonPayload.suspectedStragglersDetection.nodes.instanceId="INSTANCE_ID"
Tous les journaux de détection des traînards pour votre projet. Utilisez cette requête pour vérifier si le service de détection des retardataires est en cours d'exécution lorsqu'aucun retardataire suspect n'est détecté. (En raison des limites, vous ne pouvez pas filtrer les journaux sans retardataires suspectés par des VM spécifiques.) 
    logName=~ "/logs/compute.googleapis.com%2Fworkload_diagnostic"

Les métriques de détection des retardataires sont particulièrement utiles pour les charges de travail de ML à grande échelle pour les raisons suivantes :

  • Les charges de travail de ML à grande échelle sont très sensibles aux retardataires. Les charges de travail de ML à grande échelle utilisent l'informatique synchrone et massivement distribuée. (En d'autres termes, ils comportent de nombreux composants hautement interdépendants qui s'exécutent simultanément.) Cette architecture rend les charges de travail de ML à grande échelle très sensibles aux défaillances uniques, comme les retardataires.

  • Il est très difficile de repérer et d'identifier les retardataires dans les charges de travail de ML à grande échelle. À titre de référence, sachez qu'il existe deux types de défaillances uniques :

    • Défaillances d'arrêt : défaillances qui entraînent l'arrêt de l'ensemble du système, par exemple les erreurs d'hôte et les événements de maintenance. Elles sont relativement faciles à détecter et à résoudre.

    • Échecs lents : échecs qui entraînent une dégradation importante des performances sans plantage. Ils sont très difficiles à identifier et à déboguer.

    En raison de leur nature d'échec lent, les traînards sont intrinsèquement difficiles à remarquer et à identifier, en particulier dans les charges de travail synchrones à grande échelle.

Métriques de détection des charges de travail qui ne répondent pas

Les métriques de détection des charges de travail qui ne répondent pas vous aident à effectuer les opérations suivantes :

  • Détecter quand une charge de travail entière est bloquée (parfois appelée blocage NCCL)
  • Comprendre pourquoi la charge de travail est bloquée (par exemple, si cela est dû à un plantage de processus ou à un blocage du réseau)

Pour détecter et diagnostiquer les charges de travail qui ne répondent pas pour vos instances de calcul, utilisez les métriques suivantes :

Nom Type de métrique Séries de machines compatibles Description
Événements de charge de travail qui ne répond pas détectés à l'aide de la télémétrie NCCL instance/gpu/nccl_hang A4X Max, A4X, A4 et A3 Ultra Nombre d'événements de charge de travail non réactifs détectés, sous forme de série temporelle.

Activer la détection des charges de travail qui ne répondent pas

Pour activer la détection des charges de travail qui ne répondent pas, vous devez activer CoMMA avec la télémétrie de pulsation, un signal ping périodique qui indique qu'une charge de travail est en cours d'exécution. Pour les versions récentes de CoMMA, cette option est activée par défaut. Toutefois, si vous utilisez la version de CoMMA de la version 1.1.1 du bundle NICCL/gIB, vous devez activer manuellement la télémétrie de pulsation. Pour vérifier la version du bundle NICCL/gIB que vous utilisez, consultez Vérifier la version de NCCL et gIB.

Pour activer manuellement la télémétrie de pulsation pour CoMMA, spécifiez les variables d'environnement suivantes dans votre environnement d'entraînement :

NCCL_PROFILER_HEARTBEAT=true

NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL=10s

Utilisez NCCL_PROFILER_HEARTBEAT pour activer ou désactiver la télémétrie des pulsations, et NCCL_PROFILER_HEARTBEAT_UPLOAD_INTERVAL pour spécifier la fréquence de la télémétrie des pulsations. Pour en savoir plus, consultez Variables d'environnement CoMMA.

Désactiver la détection des charges de travail qui ne répondent pas

Pour désactiver la détection des charges de travail qui ne répondent pas, désactivez la télémétrie de pulsation dans CoMMA en spécifiant la variable d'environnement suivante dans votre environnement d'entraînement :

NCCL_PROFILER_HEARTBEAT=false

Comprendre pourquoi les charges de travail ne répondent pas

Pour comprendre pourquoi une charge de travail ne répond pas, vérifiez la valeur de l'étiquette hang_reason en procédant comme suit :

  1. Dans la console Google Cloud , accédez à la page  Explorateur de métriques.

    Accéder à l'Explorateur de métriques

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  2. Recherchez la métrique suivante :

    compute.googleapis.com/instance/gpu/nccl_hang

  3. Utilisez la fonctionnalité Agrégation, puis sélectionnez les étiquettes suivantes :

    • instance_id
    • hang_reason

Le tableau suivant liste les valeurs possibles pour l'étiquette, ce que ces valeurs signifient pour vos charges de travail et les étapes suivantes recommandées.

Valeur de l'étiquette Description Procédure recommandée
MissingHeartbeatIssue La télémétrie de pulsation s'est arrêtée pour un ou plusieurs rangs, ce qui indique généralement un plantage fatal du processus ou du nœud.
  • Vérifiez si l'instance est toujours accessible.
  • Vérifiez si les processus de charge de travail ont planté.
  • Recherchez les événements de mémoire insuffisante (OOM), tels que dmesg, dans les journaux système.
  • Recherchez les défaillances matérielles ou les erreurs NVIDIA XID.
StalledRankIssue La télémétrie de pulsation est toujours reçue, mais les rangs ne progressent pas sur les opérations NCCL.
  • Recherchez les blocages potentiels dans les opérations au niveau de l'application.
  • Vérifiez si le processus d'application est bloqué dans une opération qui l'empêche de communiquer avec d'autres, comme un calcul ou un point de contrôle.
MissingCommunicatorIssue Tous les rangs appartenant à un communicateur NCCL ont cessé de progresser.
  • Votre charge de travail a peut-être été interrompue ou ses communicateurs NCCL ont peut-être été fermés brusquement. Si vous vous attendez à ce qu'une charge de travail s'exécute sans interruption sur cette instance de VM, vérifiez si elle a été interrompue ou arrêtée de manière anormale.
NoHangIssue Valeur par défaut. Aucun problème n'a été détecté.
  • Aucune action n'est requise.

Afficher les métriques

Pour afficher les métriques de vos instances de calcul et de vos clusters Slurm, utilisez les tableaux de bord Monitoring comme suit :

Si vous rencontrez des problèmes lors de l'utilisation d'un tableau de bord, consultez Résoudre les problèmes de lenteur.

Utiliser des tableaux de bord prédéfinis

Vous pouvez utiliser des tableaux de bord Monitoring prédéfinis pour AI Hypercomputer afin d'afficher les métriques de vos instances de calcul et de vos clusters Slurm. Vous pouvez également créer une copie d'un tableau de bord prédéfini et la modifier en fonction de vos besoins.

Pour utiliser un tableau de bord prédéfini pour AI Hypercomputer, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page  Tableaux de bord :

    Accéder à la page Tableaux de bord

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  2. Dans la colonne Nom, cliquez sur le nom de l'un des tableaux de bord suivants en fonction des métriques que vous souhaitez afficher :

    • Pour surveiller l'état des instances de calcul, les performances des GPU et la détection des traînards, utilisez le tableau de bord Cluster Director Health Monitoring.

      Pour en savoir plus sur l'utilisation de ces métriques pour identifier et analyser les problèmes, utilisez également le tableau de bord du playbook GCE Interactive Playbook - Cluster Director Health Monitoring.

    • Pour surveiller l'efficacité de la transmission réseau, utilisez le tableau de bord Efficacité de la transmission Cluster Director.

    • Pour surveiller l'efficacité du réseau entre les blocs et les sous-blocs, utilisez le tableau de bord Cluster Director Block Network.

      Pour en savoir plus sur l'utilisation de ces métriques pour identifier et analyser les problèmes, utilisez également le tableau de bord du playbook GCE Interactive Playbook - Cluster Director Block Network.

    La page d'informations du tableau de bord sélectionné s'ouvre. Vous pouvez utiliser le sélecteur de période dans la barre d'outils pour modifier la période des données.

  3. Facultatif : Pour créer une copie d'un tableau de bord et la personnaliser en fonction de vos besoins, cliquez sur Copier le tableau de bord.

Créer des tableaux de bord personnalisés

Pour créer un tableau de bord Monitoring personnalisé, procédez comme suit :

  1. Choisissez les métriques à surveiller. Si vous ne l'avez pas déjà fait, consultez la section Métriques disponibles de ce document.

  2. Créer et gérer des tableaux de bord personnalisés

Afficher les journaux de détection des retardataires

Pour afficher les journaux de détection des traînards à l'aide de l'explorateur de journaux, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la pageExplorateur de journaux :

    Accéder à l'explorateur de journaux

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

    Par défaut, la page interroge tous les journaux de votre projet. Cliquez sur Arrêter la requête.

  2. Utilisez le sélecteur de période dans la barre d'outils pour sélectionner la période que vous souhaitez analyser.

  3. Dans le volet Requête, saisissez une requête pour les journaux de détection des traînards.

  4. Cliquez sur Exécuter la requête.

Voici un exemple d'entrée de journal de détection des traînards.

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

Cette entrée de journal comprend les champs suivants :

  • numNodes : nombre d'instances de calcul suspectées d'être des traînards détectées dans le projet. Dans l'exemple, quatre instances de calcul suspectées d'être des retardataires ont été détectées.
  • instanceId : ID d'une instance de calcul détectée comme un retardataire suspect.

Étapes suivantes