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
alloydbadminexiste 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 :
Connectez-vous à la base de données
postgresen tant que superutilisateurpostgres:sudo -u postgres /usr/lib/postgresql/18/bin/psql -U postgres -d postgresVé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 quittezpsql: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; \qRemplacez
LIBRARY_1,LIBRARY_2et toutes les autres bibliothèques existantes par les noms de bibliothèques renvoyés parSHOW 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.Redémarrez le serveur AlloyDB Omni pour appliquer les paramètres de préchargement :
sudo systemctl restart alloydbomni18Connectez-vous à la base de données
alloydbadminen tant que superutilisateurpostgres:sudo -u postgres /usr/lib/postgresql/18/bin/psql -U postgres -d alloydbadminCré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;Vérifiez que la bibliothèque est chargée, que l'extension est activée et que l'extension
google_insights_v2est installée dansalloydbadmin: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_librariesinclutgoogle_insights_v2,google_insights_v2.enabledrenvoieonet quepg_extensionrenvoie une ligne pourgoogle_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
DataFileReadouWALWrite, 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 quegoogle_insights_v2.qi_track_active_queries,google_insights_v2.qi_track_tagougoogle_insights_v2.qi_track_client_address.VALUE: nouvelle valeur du paramètre, par exempleon.
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
- Documentation de référence sur les insights sur les requêtes avancés
- Choisir et installer des outils de surveillance