Ce guide explique comment diagnostiquer et résoudre les problèmes courants liés aux VM Compute Engine auxquelles sont associés des GPU, y compris les erreurs matérielles et les goulots d'étranglement des performances.
Résoudre les problèmes liés aux VM GPU à l'aide de NVIDIA DCGM
Le gestionnaire de GPU du centre de données (DCGM) NVIDIA est une suite d'outils permettant de gérer et de surveiller les GPU des centres de données NVIDIA dans les environnements de clusters.
Pour utiliser DCGM afin de résoudre les problèmes dans votre environnement GPU, procédez comme suit :
- Assurez-vous d'utiliser le dernier pilote NVIDIA recommandé pour le modèle de GPU associé à votre VM. Pour consulter les versions de pilote, consultez Versions du pilote NVIDIA recommandées.
- Assurez-vous d'avoir installé la dernière version de DCGM. Pour installer la dernière version, consultez Installation de DCGM.
Diagnostiquer les problèmes
Lorsque vous exécutez une commande de diagnostic dcgmi, les problèmes signalés par l'outil de diagnostic incluent les prochaines étapes à suivre pour résoudre le problème. L'exemple suivant montre le résultat exploitable de la commande dcgmi diag -r memory -j.
{
........
"category":"Hardware",
"tests":[
{
"name":"GPU Memory",
"results":[
{
"gpu_id":"0",
"info":"GPU 0 Allocated 23376170169
bytes (98.3%)",
"status":"Fail",
""warnings":[
{
"warning":"Pending page
retirements together with a DBE were detected on GPU 0. Drain the GPU and reset it or reboot the node to resolve this issue.",
"error_id":83,
"error_category":10,
"error_severity":6
}
]
}
.........
À partir de l'extrait de sortie précédent, vous pouvez voir que GPU 0 a des pages en attente de suppression en raison d'une erreur irrécupérable. Le résultat a fourni le paramètre error_id unique et des conseils pour résoudre le problème. Pour cet exemple de résultat, nous vous recommandons de vider le GPU et de redémarrer la VM. Dans la plupart des cas, suivre les instructions de cette section du résultat peut vous aider à résoudre le problème.
Résoudre les problèmes de performances des GPU pour les VM A3
La série de machines A3 est disponible avec des GPU NVIDIA H200 ou H100. Cette série inclut les types de machines A3 Ultra (H200), A3 Mega (H100), A3 High (H100) et A3 Edge (H100).
Identifier un nœud défectueux
Les tâches d'entraînement ou de benchmark à grande échelle sur un cluster GPU multinœud peuvent cesser de répondre ou être peu performantes. Cela se produit souvent lorsqu'un ou plusieurs nœuds sont moins performants et ralentissent l'ensemble de l'opération. Cette section explique comment identifier un nœud ou une machine hôte défectueux en exécutant un test de référence NCCL ou en analysant les journaux NCCL.
Exécuter un test de benchmark NCCL
Pour identifier le groupe de nœuds à l'origine de l'échec, testez systématiquement des sous-ensembles de votre cluster à l'aide de benchmarks NCCL tels que all_reduce_perf.
- Pour identifier vos ensembles de nœuds, regroupez vos nœuds dans des ensembles logiques, par exemple des partitions dans Slurm.
- Pour créer des fichiers hôtes, créez un fichier hôte distinct pour chaque ensemble de nœuds, en listant les noms d'hôte et le nombre de GPU par nœud. Le nombre d'emplacements que vous spécifiez dépend du nombre de GPU de votre type de VM A3. Par exemple, les VM
a3-highgpu-8gdisposent de huit GPU. Vous devez donc spécifierslots=8. - Pour exécuter des benchmarks, exécutez le benchmark
all_reduce_perfsur chaque ensemble de nœuds individuellement.mpirun -x LD_LIBRARY_PATH --hostfile HOSTFILE_NAME -n TOTAL_PROCESSES \ ./build/all_reduce_perf -b 1G -e 8G -f 2 -g NUM_GPUS_PER_NODERemplacez les éléments suivants :
HOSTFILE_NAME: nom du fichier hôte contenant la liste des nœuds et le nombre de GPU par nœud pour le nœud.TOTAL_PROCESSES: nombre total de processus MPI à lancer sur tous les hôtes du groupe de nœuds.NUM_GPUS_PER_NODE: nombre de GPU par nœud. Pour tous les types de machines A3, cette valeur est8.
- Pour analyser les résultats, si un job se bloque ou affiche une bande passante de bus nettement inférieure (
busbw) sur un ensemble de nœuds particulier, il est probable que cet ensemble soit défectueux. - Pour subdiviser, si un ensemble de nœuds est défectueux, divisez son fichier hôte en deux et effectuez un nouveau test pour affiner la recherche binaire jusqu'à ce que vous identifiiez le nœud individuel qui ne fonctionne pas correctement.
Analyser les journaux NCCL
Si la méthode de référence ne permet pas d'identifier un nœud, analysez les journaux NCCL détaillés.
- Pour activer la journalisation du débogage, définissez les variables d'environnement suivantes dans la session shell où vous prévoyez d'exécuter votre charge de travail :
export NCCL_DEBUG=INFO export NCCL_DEBUG_SUBSYS=INIT,NET,COLL export NCCL_DEBUG_FILE="LOG_DIRECTORY/nccl_log.%h.%p"Remplacez
DéfinirLOG_DIRECTORYpar le répertoire dans lequel vous souhaitez stocker vos journaux.NCCL_DEBUG_FILEavec%het%pcrée des fichiers journaux uniques et non entrelacés pour chaque processus.Si vous exécutez une charge de travail multinœud à l'aide de
mpirun, propagez ces variables à tous les nœuds à l'aide de l'indicateur-x. Par exemple :mpirun -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE ... - Pour trouver la première erreur, utilisez la commande suivante afin de trouver les événements de délai avant expiration ou d'échec les plus anciens dans tous les fichiers journaux :
grep "NCCL WARN.*NET/FasTrak" LOG_DIRECTORY/* | sed 's/.*NET\/FasTrak\(.*\)/\1/g' \ | sort | head -n 20Remplacez
LOG_DIRECTORYpar le répertoire dans lequel vos journaux sont stockés. - Pour comptabiliser les opérations collectives, un nœud retardataire effectue moins d'opérations collectives. Nombre d'entrées
"opCount"pour les rangs suspects :grep "opCount" LOG_DIRECTORY/nccl_log.HOSTNAME.PID | wc -lRemplacez les éléments suivants :
LOG_DIRECTORY: répertoire dans lequel vos journaux sont stockésHOSTNAME: nom d'hôte du nœudPID: ID du processus NCCL
- Pour collecter davantage de données de journaux avant l'abandon d'un job, augmentez temporairement le délai avant expiration du transfert de données :
export NCCL_FASTRAK_DATA_TRANSFER_TIMEOUT_MS=3600000
Surveiller la limitation thermique du GPU
Les performances des VM de la série A3 peuvent se dégrader si elles atteignent régulièrement des températures supérieures à 87 °C sous charge. Pour vérifier la limitation thermique des GPU sur les nœuds d'un cluster, utilisez nvidia-smi ou dcgmi.
Utiliser nvidia-smi
Pour vérifier la température actuelle et l'état de limitation de toutes les GPU d'un nœud, exécutez la commande suivante :
nvidia-smi --query-gpu=timestamp,name,pci.bus_id,temperature.gpu,clocks_throttle_reasons.hw_slowdown --format=csv
Dans le résultat, une valeur de Active dans la colonne clocks_throttle_reasons.hw_slowdown indique que le GPU est limité en raison de températures élevées.
Utiliser dcgmi
La suite de diagnostics NVIDIA Data Center GPU Manager (DCGM) inclut des vérifications des violations thermiques. Pour exécuter un diagnostic de niveau 1, exécutez la commande suivante :
dcgmi diag -r 1
Un résultat de Warn ou Fail dans la section Thermal indique qu'une violation thermique s'est produite pendant le test. Si un non-respect des limites thermiques s'accompagne d'une limitation de la fréquence d'horloge, il est probable que le GPU surchauffe et nécessite une analyse plus approfondie.
Erreurs Xid
Après avoir créé une VM à laquelle sont associés des GPU, vous devez installer des pilotes d'appareils NVIDIA sur vos VM GPU afin que vos applications puissent accéder aux GPU. Cependant, ces pilotes renvoient parfois des messages d'erreur.
Un message Xid est un rapport d'erreur du pilote NVIDIA affiché dans le journal de noyau du système d'exploitation ou dans le journal des événements de votre VM Linux. Ces messages sont placés dans le fichier /var/log/messages. Pour en savoir plus sur les messages Xid, y compris les causes potentielles, consultez la documentation NVIDIA.
Comment Google gère-t-il les erreurs Xid ?
Google utilise des vérifications d'état passives pour évaluer les systèmes de GPU. Si le remplacement du matériel est indiqué, Google lance automatiquement une maintenance d'urgence. Google détecte les erreurs Xid et envoie de manière proactive les machines en réparation lorsque les codes d'erreur indiquent une forte probabilité de défaillance matérielle, comme Xid 74, 79 et 140. Pour certains codes Xid, qui peuvent être dus à des problèmes logiciels ou matériels, Google utilise la reconnaissance de formes pour déclencher les réparations. Par conséquent, toutes les occurrences ne donnent pas lieu à une réparation automatique.
Types d'erreurs Xid
La liste suivante décrit les trois principales catégories d'erreurs Xid et les actions de récupération recommandées :
Erreurs d'application : elles indiquent des problèmes dans le code de votre application. Les erreurs d'application incluent des Xid tels que 13, 31, 94, 95 et 137, qui indiquent différents types de non-respect de l'accès à la mémoire, semblables à un défaut de segmentation. Elles n'indiquent pas d'erreur ECC. Pour résoudre ces erreurs, NVIDIA recommande d'utiliser l'une des approches de débogage suivantes :
- Débogage direct : exécutez l'application directement dans cuda-gdb ou exécutez l'outil Compute Sanitizer memcheck.
- Débogage post-exception : exécutez l'application avec
CUDA_DEVICE_WAITS_ON_EXCEPTION=1. Lorsqu'une exception se produit, le pilote GPU fige l'état de l'application sans la quitter, ce qui vous permet d'attacher un débogueur ultérieurement (cuda-gdb -p <PID>) pour inspecter la trace de la pile en direct.
Erreurs de pilote : elles indiquent des problèmes causés par le pilote de GPU NVIDIA. Pour résoudre ces erreurs, assurez-vous d'utiliser la dernière version du pilote NVIDIA. Google surveille ces erreurs et collabore avec NVIDIA pour corriger les pilotes.
Erreurs récupérables du micrologiciel ou du matériel : elles indiquent des erreurs du micrologiciel ou du matériel qui permettent une récupération sans remplacement du matériel. Pour résoudre ces erreurs, appliquez des mesures de récupération manuelles, comme la réinitialisation du GPU ou le redémarrage de l'instance. Les erreurs récupérables au niveau du micrologiciel ou du matériel incluent les erreurs de code de correction d'erreur (ECC, Error Correcting Code) (applicables aux Xid tels que Xid 48, 63 et 64) qui indiquent différentes étapes de détection et d'atténuation des erreurs ECC. Pour en savoir plus sur la suppression de pages et l'atténuation des erreurs ECC, consultez les questions fréquentes sur la suppression dynamique de pages de NVIDIA.
Examiner les messages Xid
Pour diagnostiquer rapidement la raison pour laquelle une charge de travail GPU a échoué, a cessé de répondre ou a subi une dégradation des performances, consultez les journaux du noyau de votre instance (dmesg ou /var/log/kern.log) pour les codes d'erreur Xid NVIDIA numériques.
L'examen des tableaux d'erreurs Xid dans les sous-sections suivantes vous aide immédiatement :
- Identifier la cause première : déterminez si l'échec est dû à un bug d'application (tel qu'un accès illégal à la mémoire), à un conflit de pilote ou à un défaut matériel physique (tel que des erreurs de mémoire ECC double bit).
- Déterminez la propriété opérationnelle : vérifiez les mesures de récupération manuelle immédiates que vous devez appliquer, comme la réinitialisation des GPU, le redémarrage des VM ou l'exécution de débogueurs, par rapport aux actions de réparation automatisées et de remplacement du matériel que Google gère activement sur l'hôte.
- Suivez les étapes de récupération appropriées : évitez les procédures de dépannage inutiles et sachez précisément quand la récupération manuelle est suffisante et quand vous devez signaler l'hôte comme défectueux. Parfois, la récupération manuelle n'est pas suffisante, par exemple si la source de l'erreur se trouve dans le cache GPU (SRAM), qui ne peut pas être remappé, indiqué par
Xid 48avecSRAM Threshold Exceeded=Yes, ou si le GPU a épuisé sa banque de remappage, indiqué parXid 64: All reserved rows for bank are remapped. Dans ce cas, Google détecte que le GPU peut être remplacé et envoie la machine en réparation de manière proactive. Si vos charges de travail rencontrent des erreurs récurrentes ou si vous constatez des erreurs de mémoire répétées, vous pouvez signaler l'hôte défectueux pour lancer une réparation ou un remplacement automatiques. Pour GKE, consultez Signaler des hôtes défectueux dans GKE.
Gestion des Xid
Les sections suivantes regroupent les messages d'erreur Xid courants par catégorie technique, ainsi que les solutions et les responsabilités officielles :
- Erreurs de mémoire GPU (Xid
48,63,64,92,94,95) - Erreurs liées au processeur système du GPU (GSP) (Xid
119,120) - Erreurs d'accès illégal à la mémoire (Xid
13,31,137) - Autres messages d'erreur Xid courants (Xid
74,79,109,149)
Erreurs de mémoire du GPU
La mémoire du GPU est la mémoire disponible sur un GPU pouvant être utilisé pour le stockage temporaire de données. La mémoire du GPU est protégée par le code de correction d'erreur (ECC), qui détecte et corrige les erreurs à bit unique, et détecte et signale les erreurs à double bit non corrigibles (DBE).
Ces erreurs de mémoire sont susceptibles de se produire au cours de la durée de vie d'un GPU. Avant la sortie des GPU NVIDIA A100, la suppression dynamique de page était possible. Pour les versions de GPU NVIDIA A100 et ultérieures (telles que NVIDIA H100), la récupération d'erreur de remappage de ligne est introduite pour les erreurs HBM (DRAM). Le routage ECC est activé par défaut, et Google vous recommande vivement de le laisser activé.
Le tableau suivant répertorie les erreurs courantes de mémoire du GPU et leurs solutions suggérées :
| Message d'erreur Xid | Action du client | Action Google |
|---|---|---|
Xid 48: Double Bit ECC
Une erreur de mémoire à double bit (non corrigible) a été détectée par ECC. Cette erreur interrompt toujours la charge de travail en cours d'exécution et génère le Xid 48. |
|
Google surveille le moment où le GPU peut être remplacé par un autre matériel, par exemple si la banque de remappage HBM est épuisée ou si le GPU dépasse son seuil d'erreur SRAM à vie, et envoie de manière proactive la machine en réparation pour remplacer le GPU. |
Xid 63: ECC page retirement or row remapping recording
event
Indique qu'un événement de suppression de page dynamique ou de remappage de ligne a été enregistré en raison d'une erreur de mémoire. |
|
Google surveille les seuils d'erreur et envoie l'appareil en réparation lorsque le GPU nécessite une réparation ou un remplacement physique. |
Xid 64: ECC page retirement or row remapper recording
failure
Le message contient les informations suivantes : Xid 64: All reserved rows for bank are remapped
|
|
Lorsque la banque de remappage est épuisée ( |
Si vous recevez au moins deux des messages Xid suivants en même temps :
Le message contient les informations suivantes : Xid XX: row remap pending
|
|
Google envoie la machine en réparation si la banque de remappage est épuisée ou lorsque le GPU nécessite une réparation ou un remplacement physique. |
Xid 92: High single-bit ECC error rate |
Ce message Xid est renvoyé une fois que le pilote de GPU a corrigé une erreur récupérable. Cela ne devrait pas affecter vos charges de travail. Ce message Xid n'est fourni qu'à titre d'information. Aucune action n'est requise de votre part. |
Aucun |
Xid 94: Contained error
Indique qu'une erreur de GPU s'est produite et si l'erreur était contenue dans une seule application. Seul, le Xid 94 n'indique pas la cause première de l'erreur. Il doit être interprété en même temps que d'autres erreurs Xid simultanées pour déterminer la cause fondamentale. |
|
Aucun |
Xid 95: Uncontained error
Indique qu'une erreur de GPU s'est produite et n'était pas limitée à une seule application. Seul, le Xid 95 n'indique pas la cause première de l'erreur. Il doit être interprété en parallèle avec d'autres erreurs Xid simultanées afin de déterminer la cause fondamentale. |
|
Aucun |
Erreurs GSP
Un processeur système GPU (GSP) est un microcontrôleur qui s'exécute sur des GPU et gère certaines des fonctions de gestion matérielle de bas niveau.
| Message d'erreur Xid | Action du client | Action Google |
|---|---|---|
Xid 119: GSP RPC timeout |
|
Aucune. Si l'erreur persiste et que vous déposez une demande d'assistance, Google examine l'état du matériel ou du pilote via le workflow d'assistance. |
Xid 120: GSP error |
Erreurs d'accès illégal à la mémoire
Les Xid suivants sont renvoyés lorsque les applications rencontrent des problèmes d'accès illégal à la mémoire :
| Message d'erreur Xid | Action du client | Action Google |
|---|---|---|
|
Une violation d'accès à la mémoire a été détectée, analogue à un défaut de segmentation. Ces erreurs indiquent généralement un bug d'application où la mémoire GPU est consultée hors limites ou sur des tampons libérés, comme la déréférence d'un pointeur non valide ou d'un tableau hors limites. Elles ne représentent pas d'erreurs ECC, sauf si le Xid 48 est également présent. |
Pour résoudre ce problème, déboguez les erreurs d'accès à la mémoire dans votre application. Vous pouvez utiliser cuda-gdb, Compute Sanitizer ou cuda-memcheck. Pour en savoir plus, consultez la documentation NVIDIA Xid. |
Aucune. Dans de rares cas où la dégradation du matériel peut entraîner des erreurs d'accès illégal à la mémoire faussement signalées, vous pouvez utiliser le gestionnaire de GPU du centre de données NVIDIA (DCGM) pour exécuter |
Autres messages d'erreur Xid courants
| Message d'erreur Xid | Action du client | Action Google |
|---|---|---|
Xid 74: NVLINK error |
|
Aucun |
Xid 79: GPU has fallen off the bus
Cela signifie que le pilote ne peut pas communiquer avec le GPU, car un problème matériel a entraîné la disparition du GPU du bus PCI. |
Pour récupérer vos charges de travail, utilisez l'une des approches suivantes, selon que la maintenance d'urgence est activée ou non pour votre projet :
|
Google détecte que le GPU a été déconnecté du bus PCI et envoie l'appareil en réparation. |
Xid 109: Context switch timeout
L'erreur Xid 109 est une erreur générique signalée par le pilote de GPU NVIDIA. Elle est générée lorsqu'une instance de GPU ne parvient pas à préempter ou à changer de tâche dans le délai d'attente prévu. Google a une longue expérience dans l'étude de l'erreur Xid 109 avec NVIDIA. Les causes connues liées à des bugs de pilote sont corrigées dans les derniers pilotes. Le code Xid 109 n'est pas dû à un problème matériel. |
|
Aucun |
Xid 149 qui mentionne 0x02a, comme dans l'exemple suivant :
Cela indique un problème connu affectant le micrologiciel des GPU NVIDIA B200. |
|
Aucun |
Réinitialiser les GPU
Certains problèmes peuvent vous obliger à réinitialiser vos GPU. Pour réinitialiser les GPU, procédez comme suit :
- Pour les VM N1, G2, A2 et G4 auxquelles un ou plusieurs GPU sont associés, redémarrez la VM.
- Pour les VM G4 avec des GPU fractionnés (moins d'un GPU associé), procédez comme suit :
- Pour les instances A3, A4, A4X et A4X Max, exécutez
sudo nvidia-smi --gpu-reset.- Pour la plupart des VM Linux, l'exécutable
nvidia-smise trouve dans le répertoire/var/lib/nvidia/bin. - Pour les nœuds GKE, l'exécutable
nvidia-smise trouve dans le répertoire/home/kubernetes/bin/nvidia.
- Pour la plupart des VM Linux, l'exécutable
- Pour les instances A3, A4, A4X et A4X Max sur les nœuds GKE, vous pouvez également utiliser l'outil de réinitialisation des GPU pour automatiser la réinitialisation de tous les GPU sur un nœud. Cet outil ne nécessite que vous spécifiiez le nom du nœud cible.
Vous pouvez également réinitialiser les GPU chaque fois que vous réinitialisez une VM ou arrêtez et redémarrez une VM. Pour en savoir plus sur les états du cycle de vie des VM et sur les différences entre les actions de récupération des VM, consultez Cycle de vie des instances Compute Engine et Suspendre, arrêter ou réinitialiser des instances Compute Engine.
Ouvrir un dossier d'assistance
Si vous ne parvenez pas à résoudre les problèmes en suivant les conseils de cette page, rassemblez les informations suivantes et ouvrez une demande d'assistance :
- ID du projet dans lequel se trouvent les instances concernées.
- Liste de tous les noms ou ID d'instance dans le cluster.
- Liste des nœuds suspects identifiés lors du dépannage.
- Journaux NCCL complets et non entrelacés avec les paramètres de débogage activés.
- Résultats des vérifications de l'état du matériel (
dcgmi,nvidia-smi). - Commande exacte du benchmark ou de la charge de travail qui échoue.
- Fichiers journaux adaptés tels que le moteur hôte et les journaux de diagnostic Pour les collecter, exécutez
gather-dcgm-logs.sh, qui se trouve dans/usr/local/dcgm/scriptsdans les installations par défaut. - Rapport de bug NVIDIA. Exécutez
nvidia-bug-report.sh. Pour les GPU Blackwell, suivez Générer un rapport de bug NVIDIA pour les GPU Blackwell. - Informations sur les modifications récentes apportées à votre environnement avant l'échec.
Étapes suivantes
Consultez la section types de machines GPU.