Surveiller les performances des requêtes à l'aide des insights avancés sur les requêtes

Sélectionnez une version de la documentation :

Les insights sur les requêtes avancés vous permettent de détecter, de diagnostiquer et d'éviter les problèmes de performances des requêtes dans votre base de données AlloyDB Omni. Ils capturent la télémétrie de la base de données, y compris les statistiques de requêtes normalisées, les événements d'attente, les adresses IP client, les tags et la charge de l'instance, et conservent les métriques historiques pendant 30 jours.

Vous pouvez utiliser les insights sur les requêtes avancés pour effectuer les tâches suivantes :

  • Identifier les requêtes à latence élevée et gourmandes en ressources en analysant le temps d'exécution, le temps d'E/S, le temps d'attente, l'activité du tampon partagé et le nombre de lignes.
  • Résoudre les goulots d'étranglement en corrélant les requêtes lentes avec les événements d'attente et les classes d'événements d'attente.
  • Suivre les performances des requêtes jusqu'à des composants d'application spécifiques en taguant les requêtes avec SQLCommenter.
  • Surveiller les requêtes actives et les transactions ouvertes en temps réel, et arrêter les sessions problématiques.

Avant de commencer

Avant d'activer les insights sur les requêtes avancés, vérifiez les exigences suivantes :

  • Vous exécutez une instance AlloyDB Omni autonome installée à l'aide de packages RPM Linux.

  • Vous disposez d'un accès superutilisateur postgres à l'instance de base de données et d'un accès administrateur pour redémarrer le service de base de données.

  • La base de données alloydbadmin existe sur votre instance. AlloyDB Omni crée cette base de données par défaut lors de l'initialisation.

Activer les insights sur les requêtes avancés

Pour activer les insights sur les requêtes avancés, procédez comme suit :

  1. Connectez-vous à la base de données postgres en tant que superutilisateur postgres :

    sudo -u postgres /usr/lib/postgresql/18/bin/psql -U postgres -d postgres
  2. Vérifiez les bibliothèques chargées dans shared_preload_libraries, ajoutez les insights sur les requêtes avancés à la liste de préchargement, activez l'extension et quittez psql :

    SHOW shared_preload_libraries;
    ALTER SYSTEM SET shared_preload_libraries = 'LIBRARY_1','LIBRARY_2','google_insights_v2';
    ALTER SYSTEM SET google_insights_v2.enabled = on;
    \q
    

    Remplacez LIBRARY_1, LIBRARY_2 et toutes les autres bibliothèques existantes par les noms de bibliothèques renvoyés par SHOW shared_preload_libraries. Placez chaque entrée de bibliothèque individuelle entre des guillemets simples, par exemple 'g_stats','google_columnar_engine','google_insights_v2', et incluez toutes les bibliothèques existantes requises par AlloyDB Omni afin de ne pas les écraser.

  3. Redémarrez le serveur AlloyDB Omni pour appliquer les paramètres de préchargement :

    sudo systemctl restart alloydbomni18
  4. Connectez-vous à la base de données alloydbadmin en tant que superutilisateur postgres :

    sudo -u postgres /usr/lib/postgresql/18/bin/psql -U postgres -d alloydbadmin
  5. Créez l'extension des insights sur les requêtes avancés dans la base de données alloydbadmin :

    CREATE EXTENSION IF NOT EXISTS google_insights_v2;
    
  6. Vérifiez que la bibliothèque est chargée, que l'extension est activée et que l'extension google_insights_v2 est installée dans alloydbadmin :

    SHOW shared_preload_libraries;
    SHOW google_insights_v2.enabled;
    SELECT extname, extversion FROM pg_extension WHERE extname = 'google_insights_v2';
    

    Vérifiez que shared_preload_libraries inclut google_insights_v2, google_insights_v2.enabled renvoie on et que pg_extension renvoie une ligne pour google_insights_v2.

Paramètres de dimensions et de fonctionnalités

Dans AlloyDB Omni, les insights sur les requêtes avancés enregistrent la télémétrie de la base de données dans des tables, des vues et des fonctions SQL de la base de données alloydbadmin selon les dimensions et fonctionnalités suivantes :

  • Requêtes : utilisez-les pour identifier les instructions SQL lentes ou gourmandes en ressources lorsque la latence des requêtes augmente.
  • Types d'événements d'attente : utilisez-les pour déterminer si le processeur, les E/S de disque ou les conflits de verrouillage sont à l'origine des goulots d'étranglement de la charge de travail.
  • Événements d'attente : utilisez-les pour identifier l'événement d'attente PostgreSQL spécifique, tel que DataFileRead ou WALWrite, qui retarde l'exécution des requêtes.
  • Bases de données : utilisez-les pour comparer la consommation de ressources entre les bases de données logiques et isoler les bases de données à charge élevée sur les instances partagées.
  • Utilisateurs et adresses IP client : utilisez-les pour attribuer la charge des requêtes à des rôles de base de données ou à des adresses IP client spécifiques, et pour identifier les clients d'application problématiques.
  • Tags : utilisez-les pour corréler la charge de la base de données avec des services, des routes ou des actions ORM spécifiques de l'application tagués avec SQLCommenter.
  • Requêtes actives : utilisez-les pour diagnostiquer en temps réel les pics de performances, les transactions bloquées et les sessions de longue durée.

Lorsque vous définissez google_insights_v2.enabled sur on, AlloyDB Omni collecte automatiquement des métriques pour les requêtes, les types d'événements d'attente, les événements d'attente, les bases de données et les utilisateurs.

Pour mettre à jour un paramètre google_insights_v2.* au moment de l'exécution sans redémarrer le serveur de base de données, exécutez ALTER SYSTEM SET et rechargez la configuration :

ALTER SYSTEM SET PARAMETER_NAME = VALUE;
SELECT pg_reload_conf();

Remplacez les éléments suivants :

  • PARAMETER_NAME: nom du paramètre des insights sur les requêtes avancés à configurer, tel que google_insights_v2.qi_track_active_queries, google_insights_v2.qi_track_tag ou google_insights_v2.qi_track_client_address.
  • VALUE : nouvelle valeur du paramètre, par exemple on.

Pour obtenir une description de chaque paramètre, des vues d'observabilité correspondantes, ainsi que des métriques et des colonnes renvoyées par chaque vue, consultez la documentation de référence sur les insights sur les requêtes avancés.

Niveaux de précision temporelle

Chaque vue historique observability_service_* est disponible à trois niveaux de précision temporelle :

  • Vues de base (*_view) : intervalles de vidage de 15 secondes. Utilisez ces vues pour examiner les pics ou les incidents récents survenus au cours des 1 à 6 dernières heures.
  • Vues de niveau 1 grossier (*_coarse_1_view) : intervalles agrégés de 5 minutes pour les 2 000 requêtes les plus fréquentes. Utilisez ces vues pour analyser les tendances de performances sur une période de 6 à 24 heures.
  • Vues de niveau 2 grossier (*_coarse_2_view) : intervalles agrégés de 30 minutes pour les 2 000 requêtes les plus fréquentes. Utilisez ces vues pour analyser les tendances sur plusieurs jours jusqu'à la limite de conservation de 30 jours.

Les vues d'observabilité historiques stockent toutes les colonnes de temps d'exécution, d'attente et d'E/S en microsecondes, y compris total_execution_time, total_wait_time, total_read_time, total_write_time et time_spent.

Métriques historiques des performances des requêtes

Connectez-vous à la base de données alloydbadmin pour exécuter des requêtes de diagnostic sur les vues d'observabilité historiques. Pour en savoir plus, consultez Exécuter AlloyDB Omni et s'y connecter.

Les instructions SQL de cette section sont des exemples de requêtes pour des scénarios de dépannage courants dans les différentes dimensions. Vous pouvez personnaliser ces exemples, par exemple en modifiant la fenêtre temporelle recorded_on, en filtrant par bases de données ou rôles spécifiques, ou en interrogeant *_coarse_1_view et *_coarse_2_view pour une analyse sur plusieurs jours, afin de les adapter à votre charge de travail.

Identifier les requêtes à latence élevée

Pour trouver les 10 requêtes normalisées dont le temps d'exécution total est le plus élevé au cours de la dernière heure, exécutez l'exemple de requête suivant sur google_insights_v2.observability_service_query_view :

SELECT
  query_id,
  database,
  username,
  left(query, 100) AS normalized_query,
  sum(count) AS total_executions,
  sum(total_execution_time) AS total_execution_time_us,
  round((sum(total_execution_time)::numeric / NULLIF(sum(count), 0)), 2) AS avg_execution_time_us,
  sum(total_rows) AS total_rows,
  sum(total_shared_blocks_hit) AS shared_blocks_hit,
  sum(total_shared_blocks_read) AS shared_blocks_read
FROM google_insights_v2.observability_service_query_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
GROUP BY query_id, database, username, left(query, 100)
ORDER BY total_execution_time_us DESC
LIMIT 10;

Analyser les événements d'attente par requête

Pour identifier les catégories d'événements d'attente (wait_class) et les événements d'attente granulaires (wait_event) qui contribuent le plus au temps d'attente d'un query_id spécifique, exécutez l'exemple de requête suivant sur google_insights_v2.observability_service_wait_event_stats_by_query_view :

SELECT
  query_id,
  database,
  username,
  wait_class,
  wait_event,
  sum(count) AS wait_occurrences,
  sum(time_spent) AS total_wait_time_us
FROM google_insights_v2.observability_service_wait_event_stats_by_query_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
  AND query_id = QUERY_ID
GROUP BY query_id, database, username, wait_class, wait_event
ORDER BY total_wait_time_us DESC;

Remplacez QUERY_ID par la valeur query_id renvoyée par observability_service_query_view.

Analyser la charge de la base de données, des utilisateurs et des adresses IP des clients

Pour comparer le temps d'exécution total, le temps d'attente et le volume de requêtes entre les bases de données logiques et les rôles de base de données au cours de la dernière heure, exécutez l'exemple de requête suivant sur google_insights_v2.observability_service_db_load_conn_view :

SELECT
  database,
  username,
  sum(count) AS total_executions,
  sum(total_execution_time) AS total_execution_time_us,
  sum(total_wait_time) AS total_wait_time_us
FROM google_insights_v2.observability_service_db_load_conn_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
GROUP BY database, username
ORDER BY total_execution_time_us DESC;

Si vous activez google_insights_v2.qi_track_client_address, vous pouvez également identifier les adresses IP client connectées qui génèrent le plus de temps de requête à l'aide de l'exemple de requête suivant sur google_insights_v2.observability_service_client_address_stats_by_query_view :

SELECT
  client_address,
  username,
  database,
  query_id,
  sum(count) AS total_executions,
  sum(time_spent) AS total_time_spent_us
FROM google_insights_v2.observability_service_client_address_stats_by_query_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
GROUP BY client_address, username, database, query_id
ORDER BY total_time_spent_us DESC
LIMIT 10;

Suivre les performances des requêtes par tag

Lorsque google_insights_v2.qi_track_tag est défini sur on et que vos requêtes incluent SQLCommenter commentaires, exécutez l'exemple de requête suivant pour agréger le temps d'exécution par métadonnées de tag d'application à l'aide de google_insights_v2.observability_service_tag_view :

SELECT
  application,
  framework_name,
  framework_controller,
  framework_action,
  framework_route,
  database,
  username,
  sum(count) AS total_executions,
  sum(total_execution_time) AS total_execution_time_us,
  round((sum(total_execution_time)::numeric / NULLIF(sum(count), 0)), 2) AS avg_execution_time_us
FROM google_insights_v2.observability_service_tag_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
GROUP BY
  application,
  framework_name,
  framework_controller,
  framework_action,
  framework_route,
  database,
  username
ORDER BY total_execution_time_us DESC
LIMIT 10;

Surveiller les requêtes actives

Lorsque vous définissez google_insights_v2.qi_track_active_queries sur on, vous pouvez surveiller les requêtes en cours d'exécution et les transactions ouvertes en temps réel en interrogeant google_insights_v2.stat_activity et google_insights_v2.stat_activity_v3 dans la base de données alloydbadmin.

Ces vues exposent les connexions client actives, les durées des sessions et des transactions, ainsi que les événements d'attente actuels, tout en excluant les workers en arrière-plan et les connexions alloydbadmin.

Interroger les sessions actives et les durées des transactions

Pour identifier les requêtes en cours d'exécution sur l'instance et les transactions qui s'exécutent le plus longtemps, exécutez l'exemple de requête suivant dans alloydbadmin :

SELECT
  pid AS "Process ID",
  left(normalized_query, 40) AS "Query",
  state AS "Status",
  round(EXTRACT(EPOCH FROM (clock_timestamp() - backend_start))::numeric, 2) AS "Session duration (secs)",
  CASE
    WHEN xact_start IS NOT NULL
    THEN round(EXTRACT(EPOCH FROM (clock_timestamp() - xact_start))::numeric, 2)
    ELSE NULL
  END AS "Transaction duration (secs)",
  CASE
    WHEN query_start IS NOT NULL
    THEN round(EXTRACT(EPOCH FROM (clock_timestamp() - query_start))::numeric, 2)
    ELSE NULL
  END AS "Query duration (secs)",
  COALESCE(wait_event_type, '') AS "Wait event type",
  COALESCE(wait_event, '') AS "Wait event",
  database AS "Database",
  COALESCE(application_name, '') AS "Application name",
  username AS "Username",
  COALESCE(client_addr::text, '') AS "Client address"
FROM google_insights_v2.stat_activity_v3
WHERE state = 'active'
ORDER BY query_start ASC;

Arrêter une requête ou une transaction de longue durée

Pour arrêter une requête de longue durée ou une transaction bloquée identifiée dans google_insights_v2.stat_activity_v3, transmettez son identifiant de processus à pg_terminate_backend :

SELECT pg_terminate_backend(PROCESS_ID);

Remplacez PROCESS_ID par la valeur Process ID (pid) renvoyée par google_insights_v2.stat_activity_v3.

Désactiver les insights sur les requêtes avancés

Pour arrêter la collecte de données de télémétrie sans redémarrer votre instance AlloyDB Omni, définissez google_insights_v2.enabled sur off et rechargez la configuration :

ALTER SYSTEM SET google_insights_v2.enabled = off;
SELECT pg_reload_conf();

Pour supprimer les objets d'extension et les données historiques stockées de la base de données alloydbadmin, connectez-vous à alloydbadmin et supprimez l'extension :

DROP EXTENSION IF EXISTS google_insights_v2 CASCADE;

Étape suivante