Résoudre les problèmes

Cette page vous explique comment résoudre les problèmes liés à Cloud Profiler.

Erreurs avec la configuration de votre projet Google Cloud

Cette section répertorie les problèmes de configuration que vous pouvez rencontrer et fournit des suggestions pour les résoudre.

L'API Cloud Profiler est désactivée

L'erreur suivante se produit lorsque l'API Profiler n'est pas activée pour votre projet Google Cloud :

failed to create a profile, will retry: rpc error: code = PermissionDenied
desc = Cloud Profiler API has not been used in project 012345 before or it is disabled.

Pour résoudre ce problème, l'API Profiler doit être activée dans votre projet Google Cloud:

  1. Enable the required API.

    Enable the API

  2. Si API activée s'affiche, cela signifie que l'API est déjà activée. Sinon, cliquez sur le bouton Activer.

L'appelant ne dispose pas de l'autorisation requise

L'erreur suivante se produit lorsque vous ne disposez pas des autorisations nécessaires pour écrire des données de profilage dans un projet Google Cloud :

failed to create a profile, will retry: rpc error: code = PermissionDenied
desc = The caller does not have permission.

Pour résoudre ce problème, demandez à votre administrateur de vous accorder des autorisations supplémentaires sur ce projet. Pour obtenir une liste détaillée des autorisations et des rôles requis, consultez la page Contrôle des accès.

Erreurs avec Node.js

Cette section répertorie les problèmes que vous pouvez rencontrer lors de l'utilisation de l'agent de profilage Node.js et fournit des suggestions sur la façon de les résoudre.

L'application ne se ferme pas normalement avec Node.js

L'agent de profilage de Node.js interfère avec la sortie normale du programme. L'exécution de toutes les tâches du programme peut prendre jusqu'à une heure.

Pour résoudre ce problème, envoyez un signal SIGINT, par exemple à l'aide de Ctrl-C. Lorsque vous émettez un signal SIGINT, le processus prend fin correctement.

Erreurs avec Python

Cette section répertorie les problèmes que vous pouvez rencontrer lors de l'utilisation de l'agent de profilage Python et fournit des suggestions sur la façon de les résoudre.

Exception NotImplementedError avec Python

L'exception suivante est générée lors de l'exécution de la fonction start lorsque l'application est exécutée dans un environnement non-Linux :

NotImplementedError

Pour résoudre ce problème, exécutez votre application dans un environnement Linux.

Exception ValueError avec Python

L'exception suivante est générée lors de l'opération start lorsque les arguments de la fonction ne sont pas valides, lorsque les informations nécessaires ne peuvent pas être déterminées à partir des variables et des arguments d'environnement, ou lorsque le profilage du temps CPU et de la durée d'exécution est désactivé :

ValueError

Pour résoudre ce problème, vérifiez tous les points suivants :

  • Assurez-vous que le nom et la version du service répondent aux exigences définies à la section Arguments de nom et de version du service.
  • Si le profilage de la durée d'exécution est activé, assurez-vous que la fonction start est appelée à partir du thread principal.
  • Vérifiez que vous utilisez une version de Python compatible et que le profilage du temps CPU ou de la durée d'exécution est activé. Pour en savoir plus, consultez la section Fonction start.
  • Pour les exécutions en dehors de Google Cloud, vérifiez que vous avez défini le paramètre project_id sur start. Pour en savoir plus, consultez la section Fonction start.

Erreurs de ressource temporairement indisponible avec Python

Le journal d'erreurs contient les entrées suivantes après l'activation de Profiler :

BlockingIOError: [Errno 11] Resource temporarily unavailable
Exception ignored when trying to write to the signal wakeup fd

Ces messages se produisent lorsqu'une application s'inscrit avec le descripteur de fichier d'activation du signal, signal.set_wakeup_fd. Par défaut, si la mémoire tampon du descripteur de fichier se remplit, un avertissement est consigné dans stderr.

Lorsque Cloud Profiler collecte des profils, il déclenche les signaux à une fréquence élevée et peut entraîner le remplissage du descripteur de fichier du signal. Pour le problème GitHub, consultez la page BlockingIOError sur App Engine.

Pour résoudre ce problème, effectuez l'une des opérations suivantes :

  • Si votre application peut s'exécuter en toute sécurité lorsque des signaux sont perdus, vous pouvez utiliser Cloud Profiler. Si vous utilisez Python 3.7 ou une version ultérieure, et que vous souhaitez désactiver les messages d'avertissement, transmettez warn_on_full_buffer=False en tant que paramètre à signal.set_wakeup_fd.

  • Si votre application ne peut pas s'exécuter en toute sécurité lorsque des signaux sont perdus, nous vous recommandons de cesser d'utiliser Cloud Profiler. La poursuite de l'utilisation peut entraîner la perte de numéros de signaux et un nombre excessif d'entrées dans le journal d'erreurs.

Tous les profils sont manquants

Deux raisons courantes peuvent expliquer l'absence de profils :

  • Le service ne fonctionne pas assez longtemps pour collecter les profils.
  • Le service n'est pas configuré pour l'authentification.

Pour résoudre les problèmes liés à une courte durée d'exécution, assurez-vous que votre service s'exécute en continu pendant au moins trois minutes.

Pour résoudre les problèmes liés à l'authentification, assurez-vous que l'agent de profilage peut écrire des données dans votre projet Google Cloud :

  • Si votre service s'exécute sur Google Cloud, l'authentification est automatique, sauf lorsque vous déployez un conteneur sur Compute Engine. Lorsque vous déployez un conteneur sur Compute Engine, vous devez spécifier votre ID de projet Google Cloud dans la commande start de l'agent Profiler. Pour obtenir des instructions, consultez la page Associer l'agent à un projet Google Cloud.

  • Si votre service s'exécute en dehors de Google Cloud, vous devez créer un compte de service et associer l'agent Profiler à votre projet Google Cloud. Pour en savoir plus, consultez la page Profiler des applications s'exécutant en dehors de Google Cloud.

Profils manquants pour un type spécifique

Cette section répertorie les configurations spécifiques pour lesquelles les profils d'un ou de plusieurs types ne sont pas collectés. La première section comprend des contenus généraux et les sections restantes répertorient les problèmes liés à des langages spécifiques.

Informations générales

Si vous souhaitez afficher un type de profil spécifique, mais qu'aucun profil de ce type n'est disponible, vérifiez les éléments suivants :

Les autres sections de cette page décrivent les configurations spécifiques au langage où les données pour un type de profil ne sont pas collectées.

Go : les profils de temps CPU ne sont pas collectés pour c-archives

Lorsqu'une application Go est conçue avec l'option -buildmode définie sur c-archive ou c-shared, le profilage du temps CPU est désactivé par défaut. Les profils de tas de mémoire, de contention et de thread sont collectés. Pour en savoir plus, consultez le problème GitHub numéro 993 : Le profileur ne collecte pas de données de processeur pour le code Go dans une copie C-archive.

Pour résoudre ce problème, activez la collecte des profils de temps CPU avant que votre service n'appelle profiler.Start, puis ajoutez un appel à signal.Notify(make(chan os.Signal), syscall.SIGPROF). Pour en savoir plus sur signal.Notify, consultez la page func Notify.

Java : les profils de tas de mémoire ne sont pas collectés lorsque plusieurs profils sont activés

Vous avez activé plusieurs profileurs de segments de mémoire pour une application Java et n'avez pas de profil.

L'échantillonneur de tas de mémoire Java est activé en tant qu'agent indépendant. En conséquence, un seul profil peut être utilisé à la fois. Un bug a été ouvert pour étendre Java afin d'accepter plusieurs profileurs de segments de mémoire. Pour plus d'informations sur ce bug, consultez la section Accepter plusieurs agents pour le mécanisme d'échantillonnage de tas de mémoire.

Pour résoudre ce problème, activez un seul profileur.

Python : pas de temps CPU ni de profil d'exécution lors de l'utilisation de uWSGI

Lorsque uWSGI utilise plusieurs nœuds de calcul pour gérer les requêtes, le comportement par défaut consiste à n'effectuer l'initialisation de l'application que dans le processus maître (master). Les processus dupliqués n'effectuent pas la séquence d'initialisation.

Si vous configurez l'agent de profilage dans la séquence d'initialisation de votre application, par exemple, vous configurez l'agent de profilage dans la méthode AppConfig.ready() d'une application Django, l'agent de profilage n'est pas configuré pour les processus dupliqués.

Pour résoudre ce problème, effectuez l'initialisation de l'application dans tous les processus de nœud de calcul en définissant l'option lazy-apps sur true.

Python : vous disposez de profils de temps CPU, mais pas de profils d'exécution lorsque vous utilisez uWSGI

Le profileur collectant les durées d'exécution dépend du module de signal Python. Lorsque l'interpréteur Python est compilé pour être compatible avec les threads, la configuration par défaut désactive la gestion des signaux personnalisés pour les processus dupliqués.

Pour résoudre ce problème, activez la gestion des signaux personnalisés pour les applications uWSGI en définissant l'option py-call-osafterfork sur true.

Python : aucun profil pour les processus dupliqués

Les agents de profilage ne peuvent profiler que le processus qui les a démarrés.

Pour résoudre ce problème, si votre application duplique les processus et que vous souhaitez collecter des profils à partir des processus dupliqués, initialisez l'agent après la duplication.