Cette page a été traduite par l'API Cloud Translation.

Améliorer les performances des requêtes à l'aide de Query Insights

Cette page explique comment utiliser le tableau de bord de Query Insights pour détecter et analyser les problèmes de performances. Pour obtenir un aperçu de cette fonctionnalité, consultez la page Présentation de Query Insights.

Vous pouvez utiliser l'assistance de Gemini dans les bases de données pour vous aider à surveiller et à résoudre les problèmes liés à vos ressources AlloyDB. Pour en savoir plus, consultez la page Observer et résoudre les problèmes avec l'aide de Gemini.

Avant de commencer

Si vous ou d'autres utilisateurs devez afficher le plan de requête ou effectuer un traçage de bout en bout, vous devez disposer d'autorisations IAM (Identity and Access Management) spécifiques. Vous pouvez créer un rôle personnalisé et lui attribuer les autorisations IAM nécessaires. Vous pouvez ensuite ajouter ce rôle à tous les comptes utilisateur qui utilisent Query Insights pour résoudre des problèmes. Pour en savoir plus, consultez Créer des rôles d'administrateur personnalisés.

Le rôle personnalisé doit disposer de l'autorisation IAM suivante : cloudtrace.traces.get.

Ouvrir le tableau de bord de Query Insights

Pour ouvrir le tableau de bord Query Insights, procédez comme suit :

Dans la liste des clusters et des instances, cliquez sur une instance.
Cliquez sur Consulter la page "Insights sur les requêtes" pour obtenir des informations plus détaillées sur les requêtes et les performances sous le graphique des métriques sur la page "Vue d'ensemble du cluster", ou sélectionnez l'onglet Insights sur les requêtes dans le panneau de navigation de gauche.

Sur la page qui s'affiche ensuite, vous pouvez utiliser les options suivantes pour filtrer les résultats:

Sélecteur d'instance. Vous permet de sélectionner l'instance principale ou les instances de pool de lecture dans le cluster. Par défaut, l'instance principale est sélectionnée. Les détails affichés sont agrégés pour toutes les instances de pool de lecture connectées et leurs nœuds.
Base de données : Filtre la charge de requête sur une base de données spécifique ou sur toutes les bases de données.
Utilisateur : Filtre la charge de requête à partir de comptes utilisateur spécifiques.
Adresse du client : Filtre la charge de requête à partir d'une adresse IP spécifique.
Période : Filtre la charge de requête par périodes, mesurées en heures, jours, semaines ou autre plage personnalisée.

Le tableau de bord Query Insights fournit un sélecteur d'instance et des menus déroulants pour les bases de données, les utilisateurs et les adresses. À droite des menus déroulants, vous trouverez un filtre permettant de définir une période.

Modifier la configuration des insights sur les requêtes

Query Insights est activé par défaut sur les instances AlloyDB. Vous pouvez modifier la configuration par défaut des insights sur les requêtes.

Pour modifier la configuration de Query Insights pour une instance AlloyDB, procédez comme suit:

Console

Dans la console Google Cloud, accédez à la page Clusters.

accéder aux clusters
Cliquez sur un cluster dans la colonne Nom de la ressource.
Cliquez sur Insights sur les requêtes dans le panneau de navigation de gauche.
Sélectionnez Principal ou Pool de lecture dans la liste Insights sur les requêtes, puis cliquez sur Modifier.
Modifiez les champs Insights sur les requêtes:
1. Pour modifier la limite par défaut de 1 024 octets sur la longueur des requêtes à analyser par AlloyDB, saisissez un nombre compris entre 256 et 4 500 dans le champ Personnaliser la longueur des requêtes.
  
  L'instance redémarre après la modification de ce champ.
  
  Remarque: Une longueur de requête plus élevée nécessite davantage de mémoire.
2. Pour personnaliser vos ensembles de fonctionnalités dédiées aux insights sur les requêtes, ajustez les options suivantes:
  - Activer les plans de requête : cochez cette case pour connaître les opérations utilisées pour exécuter un échantillon d'une requête.
    Dans le champ Taux d'échantillonnage maximal, saisissez un nombre compris entre 1 et 20. Par défaut, la fréquence d'échantillonnage est définie sur 5. Pour désactiver l'échantillonnage, décochez la case Activer les plans de requête.
    Le taux d'échantillonnage détermine le nombre maximal de requêtes qu'AlloyDB peut échantillonner par minute pour l'instance par nœud.
  - Stockez les adresses IP des clients. Cochez cette case pour savoir d'où proviennent vos requêtes et pour regrouper ces informations afin d'exécuter des métriques.
  - Stockez les tags d'application. Cochez cette case pour savoir quelles applications taguées envoient des requêtes et pour regrouper ces informations afin d'exécuter des métriques. Pour en savoir plus sur les tags d'application, consultez la spécification.
Cliquez sur Mettre à jour l'instance.

gcloud

Pour activer Insights sur les requêtes pour une instance AlloyDB à l'aide de commandes Google Cloud CLI, procédez comme suit:

Installez Google Cloud CLI.
Pour initialiser gcloudCLI, exécutez la commande suivante :
```
gcloud init
```
Si vous utilisez un shell local, créez des identifiants d'authentification locaux pour votre compte utilisateur:
```
gcloud auth application-default login
```
Vous n'avez pas besoin de le faire si vous utilisez Cloud Shell.

Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.

Exemple :

gcloud alloydb instances update INSTANCE \
--cluster=CLUSTER \
--project=PROJECT \
--region=REGION \
--insights-config-query-string-length=QUERY_LENGTH \
--insights-config-query-plans-per-minute=QUERY_PLANS \
--insights-config-record-application-tags \
--insights-config-record-client-address

Remplacez les éléments suivants :

<var>CLUSTER</var>: ID de l'instance à mettre à jour
<var>CLUSTER</var>: ID du cluster de l'instance
<var>PROJECT</var>: ID du projet du cluster
<var>REGION</var>: région du cluster (par exemple, us-central1)
<var>QUERY_LENGTH</var>: longueur de la requête, comprise entre 256 et 4 500
<var>QUERY_PLANS</var>: nombre de plans de requêtes à configurer par minute

De plus, utilisez une ou plusieurs des options facultatives suivantes:

--insights-config-query-string-length: définit la limite de longueur par défaut des requêtes sur une valeur spécifiée comprise entre 256 et 4 500 octets. La longueur de requête par défaut est de 1 024 octets. Des longueurs de requête plus élevées sont plus utiles pour les requêtes analytiques, mais elles nécessitent également davantage de mémoire. Pour modifier la longueur de la requête, vous devez redémarrer l'instance. Vous pouvez toujours ajouter des tags aux requêtes qui dépassent la longueur maximale.
--insights-config-query-plans-per-minute: par défaut, un maximum de cinq échantillons de plan de requête exécutés sont capturés par minute sur l'ensemble des bases de données de l'instance. Remplacez cette valeur par un nombre compris entre 1 et 20. Pour désactiver l'échantillonnage, saisissez 0. Si vous augmentez le taux d'échantillonnage, vous obtiendrez peut-être plus de points de données, mais cela peut avoir un impact sur les performances.
--insights-config-record-client-address: stocke les adresses IP clientes d'où proviennent les requêtes et vous aide à regrouper ces données pour en extraire des métriques. Les requêtes proviennent de plusieurs hôtes. L'examen des graphiques des requêtes à partir d'adresses IP clientes peut aider à identifier la source d'un problème. Si vous ne souhaitez pas stocker les adresses IP des clients, utilisez --no-insights-config-record-client-address.
--insights-config-record-application-tags: stocke les tags d'application qui vous aident à déterminer les API et les routes MVC (model-view-controller) qui envoient des requêtes, ainsi que de regrouper les données pour en extraire des métriques. Cette option nécessite de commenter des requêtes avec un ensemble de tags spécifique. Si vous ne souhaitez pas stocker de balises d'application, utilisez --no-insights-config-record-application-tags.

Terraform

Pour configurer Insights sur les requêtes à l'aide de Terraform, utilisez la ressource google_alloydb_instance.

Exemple :

  query_insights_config {
    query_string_length = QUERY_STRING_LENGTH_VALUE
    record_application_tags = RECORD_APPLICATION_TAG_VALUE
    record_client_address = RECORD_CLIENT_ADDRESS_VALUE
    query_plans_per_minute = QUERY_PLANS_PER_MINUTE_VALUE5
  }

Remplacez les éléments suivants :

QUERY_STRING_LENGTH_VALUE: longueur de la chaîne de requête. La valeur par défaut est 1024. Tout entier compris entre 256 et 4 500 est valide.
RECORD_APPLICATION_TAG_VALUE: enregistrement de la balise d'application pour une instance. La valeur par défaut est true.
RECORD_CLIENT_ADDRESS_VALUE: enregistre l'adresse client pour une instance. La valeur par défaut est true.
QUERY_PLANS_PER_MINUTE_VALUE: nombre de plans d'exécution de requêtes capturés par Insights par minute pour toutes les requêtes combinées. La valeur par défaut est 5. Tout entier compris entre 0 et 20 est valide.

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez la section Commandes Terraform de base.

L'exemple de configuration d'instance avec la configuration d'insights sur les requêtes ajoutée doit se présenter comme suit:
```
resource "google_alloydb_instance" "instance_name" {
provider = "google-beta"
cluster       = google_alloydb_cluster.default.name
instance_id   = "instance_id"
instance_type = "PRIMARY"

machine_config {
 cpu_count = 8
}

query_insights_config {
query_string_length = 1024
record_application_tags = false
record_client_address = false
query_plans_per_minute = 5
}

depends_on = [google_alloydb_instance.default]
}
```

REST v1

Cet exemple configure les paramètres d'observabilité sur votre instance AlloyDB. Pour obtenir la liste complète des paramètres de cet appel, consultez Méthode: projects.locations.clusters.instances.patch.

Pour configurer les paramètres des insights sur les requêtes, modifiez les champs facultatifs si nécessaire. Pour obtenir la liste complète des champs de cet appel, consultez QueryInsightsInstanceConfig.

Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants:

CLUSTER_ID: ID du cluster que vous créez. Il doit commencer par une lettre minuscule et peut contenir des lettres minuscules, des chiffres et des traits d'union.
PROJECT_ID: ID du projet dans lequel vous souhaitez placer le cluster.
LOCATION_ID: ID de la région du cluster.
INSTANCE_ID: nom de l'instance principale que vous souhaitez créer.

Pour modifier la configuration de votre instance, utilisez la requête PATCH suivante:

PATCH https://alloydb.googleapis.com/v1beta/{instance.name=projects/PROJECT_ID/locations/LOCATION_ID/clusters/CLUSTER_ID/instances/INSTANCE_ID?updateMask=observabilityConfig.enabled}

Le corps de la requête JSON qui configure tous les champs d'observabilité se présente comme suit:

{
  "queryStringLength": integer,
  "recordApplicationTags": boolean,
  "recordClientAddress": boolean,
  "queryPlansPerMinute": integer
}

Procédure pour améliorer les performances des requêtes

Query Insights résout les problèmes liés aux requêtes AlloyDB à la recherche de problèmes de performances. Le tableau de bord d'Insights sur les requêtes affiche la charge de la requête en fonction des facteurs que vous sélectionnez. La charge de la requête correspond au calcul du travail total pour toutes les requêtes de l'instance au cours de la période sélectionnée.

Query Insight vous aide à détecter et à analyser les problèmes de performances des requêtes. Query Insights vous permet de résoudre les requêtes en quatre étapes :

Affichez la charge de la base de données pour toutes les requêtes
Identifiez une requête ou un tag potentiellement problématique
Examinez la requête ou le tag pour identifier les problèmes
Tracez la source du problème.

Afficher la charge de la base de données pour toutes les requêtes

Le tableau de bord de premier niveau d'Insights sur les requêtes affiche le graphique Charge de la base de données – toutes les principales requêtes à l'aide de données filtrées. La charge de la requête de la base de données est une mesure du travail (en secondes du processeur) ayant exécuté les requêtes de la base de données sélectionnée au fil du temps. Chaque requête en cours d'exécution utilise ou attend des ressources du processeur, des ressources d'E/S ou des ressources de verrouillage. La charge des requêtes de la base de données correspond au ratio du temps pris par toutes les requêtes effectuées sur une période donnée par rapport à la durée d'exécution.

Affiche le graphique de charge de base de données avec une charge en termes de capacité du processeur, de processeur et de temps d'attente du processeur, de temps d'attente d'E/S et de temps d'attente de verrouillage.

Les lignes colorées dans le graphique indiquent la charge de la requête, divisée en quatre catégories :

Capacité du processeur : nombre de processeurs disponibles sur l'instance
Processeur et Attente du processeur : ratio entre le temps pris par les requêtes dans un état actif par rapport à la durée d'exécution. Les temps d'attente E/S et de verrouillage ne bloquent pas les requêtes dont l'état est actif. Cette métrique peut indiquer que la requête utilise le processeur ou qu'elle attend que le programmeur Linux planifie le processus du serveur exécutant la requête alors que d'autres processus utilisent le processeur.

Remarque : La charge du processeur tient compte à la fois de l'environnement d'exécution et du temps d'attente du programmeur Linux chargé de planifier le processus du serveur en cours d'exécution. Par conséquent, la charge du processeur peut dépasser la limite maximale de cœur.
Attente E/S : temps pris par les requêtes en attente d'E/S par rapport à la durée d'exécution. L'attente E/S comprend l'attente E/S en lecture et l'attente E/S en écriture. Consultez la table des événements PostgreSQL. Si vous souhaitez une répartition des informations sur les temps de verrouillage, vous pouvez les consulter dans Cloud Monitoring. Pour en savoir plus, consultez les graphiques de métriques.
Attente verrouillage : temps pris par les requêtes en attente de verrous par rapport à la durée d'exécution. Cela inclut les temps d'attente associés aux valeurs Lock, LwLock et BufferPin. Si vous souhaitez une répartition des informations relatives aux temps de verrouillage, vous pouvez les consulter dans Cloud Monitoring. Pour en savoir plus, consultez les graphiques de métriques.

Consultez ensuite le graphique et utilisez les options de filtrage pour répondre aux questions suivantes :

La charge de la requête est-elle élevée ? Le graphique a-t-il connu un pic ou augmenté au fil du temps ? Si vous ne constatez pas de charge élevée, le problème ne concerne pas vos requêtes.
Depuis combien de temps la charge est-elle élevée ? Est-elle élevée uniquement maintenant ? Ou est-elle élevée depuis longtemps ? Utilisez la sélection de plages pour sélectionner différentes périodes et déterminer depuis combien de temps le problème persiste. Vous pouvez également faire un zoom avant pour afficher une période dans laquelle des pics de la charge de requête ont été observés. Vous pouvez faire un zoom arrière pour afficher une semaine de la chronologie.
Qu'est-ce qui provoque la charge élevée ? Vous pouvez sélectionner des options pour examiner la capacité du processeur, l'attente du processeur et le processeur, l'attente de verrouillage ou l'attente E/S. Le graphique de chacune de ces options s'affiche dans une couleur différente, ce qui vous permet d'identifier celle qui présente la charge la plus élevée. La ligne bleu foncé sur le graphique indique la capacité maximale du processeur du système. Il vous permet de comparer la charge de requête avec la capacité maximale de processeur du système. Cette comparaison vous permet de savoir si une instance manque de ressources de processeur.
Quelle base de données subit la charge ? Sélectionnez différentes bases de données dans le menu déroulant "Bases de données" pour trouver celles avec les charges les plus élevées.
Des utilisateurs spécifiques ou des adresses IP entraînent-ils des charges plus élevées ? Sélectionnez des utilisateurs et des adresses différents dans les menus déroulants pour comparer ceux qui entraînent des charges plus élevées.

Filtrer la charge de la base de données

Les sections Requêtes et tags vous permettent de filtrer ou de trier la charge des requêtes pour une requête sélectionnée ou un tag de requête SQL.

Filtrer par requêtes

La table REQUÊTES fournit un aperçu des requêtes qui provoquent les charges de requête les plus élevées. Le tableau affiche toutes les requêtes normalisées pour la période et les options sélectionnées dans le tableau de bord d'Insights sur les requêtes.

Par défaut, le tableau trie les requêtes par durée d'exécution totale au cours de la période sélectionnée.

Affiche le graphique de charge de la base de données avec une charge pour les requêtes, et les filtres sélectionnés pour la capacité du processeur, le processeur et le temps d'attente du processeur, le temps d'attente d'E/S et le temps d'attente de verrouillage.

Pour filtrer le tableau, sélectionnez une propriété dans Filtrer les requêtes. Pour trier le tableau, sélectionnez un en-tête de colonne. Le tableau affiche les propriétés suivantes :

Chaîne de requête Chaîne de requête normalisée. Par défaut, Query Insights affiche uniquement 1 024 caractères dans la chaîne de requête.

Les requêtes libellées UTILITY COMMAND incluent généralement les commandes BEGIN, COMMIT et EXPLAIN, ou les commandes de wrapper.
Base de données : Base de données sur laquelle la requête a été exécutée
Charge par temps total/Charge par processeur/Charge par temps d'attente E/S/Charge par temps d'attente de verrouillage. Ces options vous permettent de filtrer des requêtes spécifiques afin de trouver la charge la plus élevée pour chaque option.
Temps d'exécution moyen (ms) : Temps total nécessaire à toutes les sous-tâches pour effectuer la requête sur tous les nœuds de calcul parallèles. Pour en savoir plus, consultez Durée et temps d'exécution moyens.
Nombre d'appels : Nombre de fois que la requête a été appelée par l'application
Nombre moyen de lignes récupérées : Nombre moyen de lignes récupérées pour la requête

Insights sur les requêtes affiche les requêtes normalisées, ce qui signifie que les valeurs constantes littérales sont remplacées par $1, $2, etc. Exemple :

UPDATE
  "demo_customer"
SET
  "customer_id" = $1::uuid,
  "name" = $2,
  "address" = $3,
  "rating" = $4,
  "balance" = $5,
  "current_city" = $6,
  "current_location" = $7
WHERE
  "demo_customer"."id" = $8

La valeur de la constante est ignorée afin que Query Insights puisse agréger des requêtes similaires et supprimer toute information personnelle pouvant être affichée par la constante.

Filtrer par tags de requête

Pour dépanner une application, vous devez d'abord ajouter des tags à vos requêtes SQL.

Query Insights offre également une surveillance centrée sur les applications afin de diagnostiquer les problèmes de performances des applications créées à l'aide d'ORM.

Si vous êtes responsable de l'ensemble de la pile d'applications, Query Insights assure la surveillance des requêtes à partir d'une vue de l'application. L'ajout de tags aux requêtes vous aide à détecter les problèmes liés à des constructions de niveau supérieur, telles que l'utilisation de la logique métier, d'un microservice ou d'une autre construction. Vous pouvez des tags aux requêtes en fonction de la logique métier, par exemple à l'aide des tags de paiement, d'inventaire, d'analyse commerciale ou de livraison. Vous pouvez ensuite identifier la charge de requête créée par les différents types de logique métier. Par exemple, vous pouvez trouver des événements inattendus, tels qu'un pic pour un tag d'analyse commerciale à 13 h. Vous pourriez également constater une croissance inattendue d'un service de paiement au cours de la semaine précédente.

Les tags de charge de requête fournissent la répartition de la charge des requêtes pour le tag sélectionné au fil du temps.

Pour calculer la Charge de base de données pour un tag, Query Insights utilise le temps nécessaire à chaque requête utilisant le tag sélectionné. Query Insights calcule le délai d'exécution à la minute à l'aide de l'heure d'exécution.

Dans le tableau de bord de Query Insights, sélectionnez TAGS pour afficher le tableau des tags. Le tableau TAGS trie les tags en fonction de leur charge totale par durée totale.

La figure 5 illustre le tableau de bord de Query Insights, avec une charge pour les tags.
Liste de tags affichée sous le graphique

Vous pouvez trier la table en sélectionnant une propriété dans Filtrer les requêtes ou en cliquant sur un en-tête de colonne. Le tableau affiche les propriétés suivantes :

Action, contrôleur, framework, route, application, pilote de base de données. Chaque propriété que vous avez ajoutée à vos requêtes s'affiche sous la forme d'une colonne. Vous devez ajouter au moins une de ces propriétés si vous souhaitez effectuer un filtrage par tags.
Charge par temps total/Charge par processeur/Charge par temps d'attente E/S/Charge par temps d'attente de verrouillage. Ces options vous permettent de filtrer des requêtes spécifiques afin de trouver la charge la plus élevée pour chaque option.
Temps d'exécution moyen (ms) : Temps total nécessaire à toutes les sous-tâches pour effectuer la requête sur tous les nœuds de calcul parallèles. Pour en savoir plus, consultez Durée et temps d'exécution moyens.
Nombre d'appels : Nombre de fois que la requête a été appelée par l'application
Nombre moyen de lignes récupérées : Nombre moyen de lignes récupérées pour la requête
Base de données : Base de données sur laquelle la requête a été exécutée

Examiner une requête ou un tag spécifique

Pour déterminer si une requête ou un tag est la cause principale du problème, procédez comme suit à partir de l'onglet Requêtes ou Tags :

Cliquez sur l'en-tête Load by total time (Charge par temps total) pour trier la liste par ordre décroissant.
Cliquez sur la requête ou le tag qui semble avoir la charge la plus élevée et dure plus longtemps que les autres.

Un tableau de bord s'ouvre et affiche les détails de la requête ou du tag sélectionné.

Si vous avez sélectionné une requête, un aperçu de celle-ci s'affiche:

Affiche une version tronquée de la requête sélectionnée.

Si vous avez sélectionné une balise, une présentation de celle-ci s'affiche.

Examiner la charge d'une requête ou d'un tag spécifiques

Le graphique Charge de la base de données – requête spécifique montre le travail (en secondes de processeur) effectué au cours du temps par la requête normalisée sélectionnée dans la requête sélectionnée. Pour calculer la charge, elle utilise le temps pris par les requêtes normalisées à la limite de la minute par rapport à la durée d'exécution. En haut du tableau, les 1 024 premiers caractères de la requête normalisée (où les littéraux sont supprimés pour des raisons d'agrégation et d'informations personnelles) s'affichent. Comme pour le graphique des requêtes totales, vous pouvez filtrer la charge d'une requête spécifique par base de données, utilisateur et adresse du client. La charge de la requête est divisée en capacité du processeur, processeur et temps d'attente du processeur, temps d'attente d'E/S et temps d'attente de verrouillage.

Illustre les graphiques de charge et de latence de la base de données pour une requête spécifique.

Le graphique (Charge de la base de données – tags spécifiques) montre le travail (en secondes de processeur) effectué au cours du temps par les requêtes correspondant aux tags spécifiés, dans la base de données sélectionnée. Comme pour le graphique des requêtes totales, vous pouvez filtrer la charge d'un tag spécifique par base de données, utilisateur et adresse du client.

Examiner la latence

Vous utilisez le graphique Latence pour examiner la latence de la requête ou du tag. La latence correspond au temps d'exécution de la requête normalisée en temps réel écoulé. Le tableau de bord de la latence montre la latence des 50e, 95e et 99e centiles afin de détecter les comportements présentant des anomalies.

Affiche le graphique de latence de la requête pour une requête spécifique avec les filtres sélectionnés pour la capacité du processeur, le temps d'attente du processeur et le processeur, le temps d'attente d'E/S et le temps d'attente de verrouillage.

La latence des requêtes parallèles est mesurée en temps d'exécution, même si la charge de la requête peut être plus élevée pour la requête en raison de l'utilisation de plusieurs cœurs pour exécuter une partie de la requête.

Essayez de préciser le problème en examinant les éléments suivants :

Qu'est-ce qui provoque la charge élevée ? Sélectionnez des options pour examiner la capacité du processeur, le temps d'attente du processeur et le processeur, le temps d'attente de verrouillage ou le temps d'attente d'E/S.
Depuis combien de temps la charge est-elle élevée ? Est-elle élevée uniquement maintenant ? Ou est-elle élevée depuis longtemps ? Modifiez les périodes pour trouver la date et l'heure auxquelles la charge s'est mal exécutée.
Y a-t-il eu des pics de latence ? Vous pouvez modifier la période pour étudier la latence historique de la requête normalisée.

Une fois que vous avez trouvé les zones et les heures où la charge était la plus élevée, vous pouvez afficher plus de détails.

Examiner la latence dans un cluster

Vous utilisez le graphique Latence P99 sur la même requête dans le cluster pour examiner la latence P99 de la requête ou du tag sur les instances du cluster.

Examiner les opérations dans un plan de requête échantillonné

Un plan de requête prend un échantillon de votre requête et le divise en opérations individuelles. Il décrit et analyse chaque opération dans la requête. Le graphique des exemples de plan de requête affiche tous les plans de requête en cours d'exécution à des heures particulières et la durée d'exécution de chaque plan.

Affiche un graphique pour des exemples de plans de requête, ainsi que l'heure à laquelle elles ont été exécutées au bas du graphique (axe X) et le nombre de secondes pendant lesquelles elles ont été exécutées sur la droite (axe Y).

Pour afficher les détails de l'exemple de plan de requête, cliquez sur les points du graphique Exemples de plans de requête. Il existe un aperçu des exemples de plans de requête exécutés pour la plupart des requêtes, mais pas de la totalité. Les détails développés montrent un modèle de toutes les opérations du plan de requête. Chaque opération affiche la latence, les lignes renvoyées et le coût de cette opération. Lorsque vous sélectionnez une opération, vous pouvez afficher plus de détails, tels que des blocs d'appels partagés, le type de schéma, les boucles réelles, des lignes de plan, etc.

Le plan de requête indique la latence et le coût de chaque opération exécutée pour la requête.

Essayez de préciser le problème en examinant les questions suivantes :

Quelle est la consommation des ressources ?
Quel est le rapport avec les autres requêtes ?
La consommation évolue-t-elle au fil du temps ?

Tracer la source du problème

Pour vous aider à identifier la source spécifique du problème, telle qu'un modèle, une vue, un contrôleur, une route, un hôte ou un utilisateur spécifique, Query Insights fournit une trace en contexte de l'application de bout en bout pour comprendre ce qui se passe au niveau de la couche de base de données pour une requête spécifique et trouver la source d'une requête problématique par modèle, vue, contrôleurs et route. Si vous activez OpenCensus ou OpenTelemetry, les informations sur les délais OpenCensus sont envoyées à la base de données avec les informations sur le tag dans les commentaires SQL. Toutes les traces de l'application vers Cloud Logging sont associées aux traces du plan de requête de la base de données pour identifier la source du problème. Vous pouvez cliquer sur l'onglet END to END (BOUT EN BOUT) sur l'écran d'exemple de requête pour examiner la trace contextuelle.

Sélectionner un tag sous "De bout en bout" pour afficher des informations spécifiques sur le tag. Le résumé affiche les RPC et la durée totale en ms pour chaque opération de ce tag.

Pour déterminer le client et l'utilisateur à l'origine du problème, utilisez les adresses du principal client et les tables des principaux utilisateurs afin d'identifier les charges les plus élevées. Vous pouvez ajouter un utilisateur ou une adresse IP au filtre pour analyser plus précisément un utilisateur ou une adresse client spécifique.

L'image présente des informations sur les principales adresses et les principaux utilisateurs.

Pour les requêtes, vous pouvez utiliser Cloud Trace pour afficher la trace de bout en bout pour chaque étape du plan de requête. Dans le tableau de bord d'Insights sur les requêtes, cliquez sur le bouton Afficher dans la trace pour ouvrir l'outil Cloud Trace.

Le graphique de trace affiche toutes les traces qui ont été exécutées pour la période sélectionnée, dans ce cas, une heure. La page contient également un tableau indiquant la latence, la méthode HTTP, l'URL, ainsi que l'heure à laquelle la trace a été exécutée (cd).

Pour en savoir plus sur l'utilisation des outils dans Cloud Trace, consultez la page Rechercher et afficher des traces.

Ajouter des tags aux requêtes SQL

L'ajout de tags aux requêtes SQL simplifie le dépannage des applications. Vous pouvez ajouter automatiquement des tags à vos requêtes SQL avec sqlcommenter à l'aide d'un mappage objet-relationnel (ORM, Object-Relational Mapping) ou manuellement.

Utiliser sqlcommenter avec ORM

Lorsque ORM est utilisé au lieu d'écrire directement des requêtes SQL, il est possible que vous ne trouviez pas le code d'application qui engendre le problème de performances. Vous aurez peut-être également des difficultés à analyser l'impact du code de votre application sur les performances des requêtes. Pour résoudre ce problème, Query Insights fournit une bibliothèque Open Source appelée sqlcommenter, une bibliothèque d'instrumentation ORM. Cette bibliothèque est utile pour les développeurs qui utilisent ORMs et les administrateurs pour détecter le code d'application qui pose problème.

Si vous utilisez ensemble ORM et sqlcommenter, ces tags sont créés automatiquement sans que vous ayez besoin d'ajouter de code personnalisé à votre application, ni de modifier un code existant.

Vous pouvez installer sqlcommenter sur le serveur d'applications. La bibliothèque d'instrumentation permet de propager des informations liées à l'application en rapport avec votre framework MVC dans la base de données, ainsi que les requêtes en tant que commentaire SQL. La base de données récupère ces tags, puis commence à enregistrer et à agréger les statistiques en fonction de leurs tags, qui sont orthogonaux avec des statistiques agrégées par requêtes normalisées. Query Insights affiche les tags afin que vous puissiez savoir quelle application est à l'origine de la charge de la requête. Ces informations vous aident à identifier le code d'application qui pose problème.

Lorsque vous examinez les résultats dans les journaux de la base de données SQL, ils se présentent comme suit :

SELECT * from USERS /*action='run+this',
controller='foo%3',
traceparent='00-01',
tracestate='rojo%2'*/

Les tags acceptées incluent le nom du contrôleur, la route, le framework et l'action.

L'ensemble des ORM dans sqlcommenter est compatible avec différents langages de programmation :

Python	Django psycopg2 Sqlalchemy Flask
Java	Hibernate Printemps
Ruby	Rails
Node.js	Knex.js Sequelize.js Express.js

Pour plus d'informations sur sqlcommenter et sur son utilisation dans votre framework ORM, consultez la documentation de sqlcommenter dans GitHub.

Ajouter des tags manuellement à l'aide de sqlcommenter

Si vous n'utilisez pas ORM, vous devez ajouter manuellement des tags sqlcommenter à vos requêtes SQL. Dans votre requête, vous devez améliorer chaque instruction SQL à l'aide d'un commentaire contenant une paire clé/valeur sérialisée. Utilisez au moins l'une des clés suivantes :

action=''
controller=''
framework=''
route=''
application=''
db driver=''

Query Insights supprime toutes les autres clés. Consultez la documentation sqlcommenter pour connaître le format approprié pour les commentaires SQL.

Durée et temps d'exécution

Query Insights fournit une métrique Temps d'exécution moyen (ms), qui indique le temps total que toutes les sous-tâches prennent pour toutes les tâches en parallèle pour terminer la requête. Cette métrique peut vous aider à optimiser l'utilisation globale des ressources des bases de données en détectant et en optimisant les requêtes qui génèrent le plus de surcharge de processeur.

Pour afficher le temps écoulé, vous pouvez mesurer la durée d'une requête en exécutant la commande \timing sur le client psql. Il mesure le temps écoulé entre la réception de la requête et l'envoi d'une réponse par le serveur PostgreSQL. Cette métrique peut vous aider à analyser pourquoi une requête donnée prend trop de temps et à décider si vous devez l'optimiser pour qu'elle s'exécute plus rapidement.

Si une requête est effectuée en mode monothread par une seule tâche, la durée et le temps d'exécution moyen restent les mêmes.