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.
Si vous souhaitez utiliser DCGM pour 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 retrait en raison d'une erreur non ré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 sortie, il est recommandé 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 (
busbw) nettement inférieure 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 retestez-le pour affiner la recherche dichotomique 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, vous devez propager 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 du 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 fréquence de tous 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.
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 et liste de tous les noms ou ID d'instance du 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). - La 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.
Examiner les messages 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.
La section suivante fournit des conseils sur la gestion de certains messages Xid regroupés par les types les plus courants : erreurs de mémoire de GPU, erreurs de processeur système du GPU (GSP) et erreurs d'accès illégal à la mémoire.
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 (DBE).
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. Le routage ECC est activé par défaut. Nous vous recommandons vivement de laisser le chiffrement ECC activé.
Voici les erreurs courantes de mémoire du GPU et leurs solutions suggérées.
| Message d'erreur Xid | Solution |
|---|---|
Xid 48: Double Bit ECC |
|
Xid 63: ECC page retirement or row remapping recording
event |
|
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
|
|
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
|
|
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. |
Xid 94: Contained ECC error |
|
Xid 95: Uncontained ECC error |
|
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 | Solution |
|---|---|
Xid 119: GSP RPC timeout |
|
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 :
Xid 13: Graphics Engine ExceptionXid 31: GPU memory page fault
Les erreurs d'accès à la mémoire illégales sont généralement provoquées par vos charges de travail qui tentent d'accéder à la mémoire déjà libérée ou hors limites. Cela peut être dû à des problèmes tels que le déréférencement d'un pointeur non valide ou d'un tableau de limites sortantes.
Pour résoudre ce problème, vous devez déboguer votre application. Pour déboguer votre application, vous pouvez utiliser cuda-memcheck et CUDA-GDB.
Dans certains cas très rares, la dégradation matérielle peut entraîner l'affichage d'erreurs d'accès à la mémoire illégales. Pour déterminer si le problème concerne votre matériel, utilisez le gestionnaire de GPU du centre de données (DCGM) NVIDIA.
Vous pouvez exécuter dcgmi diag -r 3 ou dcgmi diag -r 4 pour exécuter différents niveaux de couverture et de durée des tests. Si vous constatez que le problème concerne le matériel, déposez une demande auprès du Cloud Customer Care.
Autres messages d'erreur Xid courants
| Message d'erreur Xid | Solution |
|---|---|
Xid 74: NVLINK error |
|
Xid 79: GPU has fallen off the bus
Cela signifie que le pilote ne peut pas communiquer avec le GPU. |
Redémarrez la VM. |
Xid 149 qui mentionne 0x02a, comme dans l'exemple suivant :
Cela indique un problème connu affectant le micrologiciel des GPU NVIDIA B200. |
|
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 et A2, redémarrez la VM.
- Pour les VM G4 auxquelles est associé moins d'un GPU, supprimez et recréez la VM.
- Pour les VM A3 et A4, 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. - Si vous utilisez des nœuds GKE, vous pouvez utiliser l'outil de réinitialisation des GPU pour automatiser la réinitialisation de tous les GPU d'un nœud. Cet outil ne nécessite que vous spécifiiez le nom du nœud cible.
- Pour la plupart des VM Linux, l'exécutable
Vous pouvez également réinitialiser les GPU lorsque vous réinitialisez une VM ou redémarrez une VM.
Si des erreurs persistent après la réinitialisation du GPU, vous devez supprimer et recréer la VM.
Si l'erreur persiste après une suppression et une recréation, déposez une demande auprès du Cloud Customer Care pour déplacer la VM vers l'étape de réparation.
Étapes suivantes
Consultez la section types de machines GPU.