Statistiques sur les requêtes actives les plus anciennes

Les requêtes actives les plus anciennes, également appelées requêtes les plus longues, répertorient les requêtes actives dans votre base de données, triées en fonction de leur durée d'exécution. L'analyse de ces requêtes permet d'identifier les causes des problèmes de latence du système et d'utilisation intensive du processeur au fur et à mesure qu'ils se produisent.

Spanner fournit une table intégrée,SPANNER_SYS.OLDEST_ACTIVE_QUERIES, qui répertorie les requêtes en cours d'exécution, y compris les requêtes contenant des instructions LMD, triées par heure de début, par ordre croissant. Elle n'inclut pas les requêtes de flux de modifications.

Si de nombreuses requêtes sont en cours d'exécution, les résultats peuvent être limités à un sous-ensemble du nombre total de requêtes en raison des contraintes de mémoire appliquées par le système sur la collecte de ces données. Par conséquent, Spanner fournit une table supplémentaire, SPANNER_SYS.ACTIVE_QUERIES_SUMMARY, qui affiche des statistiques récapitulatives pour toutes les requêtes actives (à l'exception des requêtes de flux de modifications). Vous pouvez récupérer les informations de ces deux tables intégrées à l'aide d'instructions SQL.

Dans cet article, nous allons décrire les deux tables, afficher des exemples de requêtes utilisant ces tables et, pour finir, nous vous montrerons comment les utiliser pour limiter les problèmes causés par les requêtes actives.

Accéder aux statistiques sur les requêtes actives les plus anciennes

Les données SPANNER_SYS ne sont disponibles que via des interfaces SQL. Par exemple :

• Page Spanner Studio d'une base de données dans la console Google Cloud

• La commande gcloud spanner databases execute-sql

• La méthode executeSql ou executeStreamingSql

Spanner n'est pas compatible avec SPANNER_SYS pour les méthodes de lecture unique suivantes :

• effectuer une lecture forte à partir d'une ou de plusieurs lignes d'une table ;
• effectuer une lecture non actualisée à partir d'une ou de plusieurs lignes d'une table ;
• lire à partir d'une ou de plusieurs lignes d'un index secondaire.

Statistiques pour l'entité "OLDEST_ACTIVE_QUERIES"

SPANNER_SYS.OLDEST_ACTIVE_QUERIES renvoie la liste des requêtes actives triées par heure de début. Si de nombreuses requêtes sont en cours d'exécution, les résultats peuvent être limités à un sous-ensemble du nombre total de requêtes en raison des contraintes de mémoire appliquées par Spanner sur la collecte de ces données. Pour afficher des statistiques récapitulatives de toutes les requêtes actives, consultez ACTIVE_QUERIES_SUMMARY.

Schéma de la table de statistiques sur les requêtes actives les plus anciennes

Nom de la colonne	Type	Description
START_TIME	TIMESTAMP	Heure de début de la requête.
TEXT_FINGERPRINT	INT64	L'empreinte digitale est un hachage du tag de la requête ou, si aucun tag n'est présent, un hachage du texte de la requête.
TEXT	STRING	Texte de l'instruction de requête.
TEXT_TRUNCATED	BOOL	Si le texte de la requête dans le champ TEXT est tronqué, cette valeur est TRUE. Si le texte de la requête n'est pas tronqué, cette valeur est FALSE.
SESSION_ID	STRING	ID de la session qui exécute la requête.
QUERY_ID	STRING	ID de la requête. Vous pouvez utiliser cet ID avec CALL cancel_query(query_id) pour annuler la requête.
CLIENT_IP_ADDRESS	STRING	Adresse IP du client qui a demandé la requête. Il est parfois possible que l'adresse IP du client soit masquée. L'adresse IP affichée ici est cohérente avec les journaux d'audit et suit les mêmes consignes de masquage. Pour en savoir plus, consultez Adresse IP de l'appelant dans les journaux d'audit. Nous vous recommandons de demander l'adresse IP du client uniquement lorsque cela est nécessaire, car les demandes d'adresses IP de clients peuvent entraîner une latence supplémentaire.
API_CLIENT_HEADER	STRING	En-tête api_client du client.
USER_AGENT_HEADER	STRING	En-tête user_agent que Spanner a reçu du client.
SERVER_REGION	STRING	Région dans laquelle le serveur racine Spanner traite la requête. Pour en savoir plus, consultez Durée de vie d'une requête.
PRIORITY	STRING	Priorité de la requête. Pour afficher les priorités disponibles, consultez RequestOptions.
TRANSACTION_TYPE	STRING	Type de transaction de la requête. Les valeurs possibles sont READ_ONLY, READ_WRITE et NONE.

Exemples de requêtes

Vous pouvez exécuter les exemples d'instructions SQL suivants à l'aide des bibliothèques clientes, de la Google Cloud CLI ou de la consoleGoogle Cloud .

Lister les requêtes actives en cours les plus anciennes

La requête suivante renvoie la liste des requêtes les plus anciennes exécutées en fonction de l'heure de début de la requête.

SELECT start_time,
       text_fingerprint,
       text,
       text_truncated,
       session_id,
       query_id,
       api_client_header,
       server_region,
       priority,
       transaction_type
FROM spanner_sys.oldest_active_queries
ORDER BY start_time ASC;

Sortie de la requête

Le tableau suivant présente le résultat de l'exécution de la requête mentionnée précédemment :

start_time	text_fingerprint	text	text_truncated	session_id	query_id	api_client_header	server_region	priorité	transaction_type
2025-05-20T03:29:54.287255Z	-3426560921851907385	SELECT a.SingerId, a.AlbumId, a.TrackId, b.SingerId as b_id, b.AlbumId as b_albumid, b.TrackId as b_trackId FROM Songs as a CROSS JOIN Songs as b;	FALSE	AG46FS6K3adF	9023439241169932454	gl-go/1.25.0-20250216-RC00 gccl/1.73.0 gapic/1.73.0 gax/2.14.1 grpc/1.69.2	us-central1	PRIORITY_HIGH	READ_ONLY
2025-05-20T03:31:52.40808Z	1688332608621812214	SELECT a.SingerId, a.AlbumId, a.TrackId, a.SongName, s.FirstName, s.LastName FROM Songs as a JOIN Singers as s ON s.SingerId = a.SingerId WHERE STARTS_WITH(s.FirstName, 'FirstName') LIMIT 1000000;	FALSE	AG46FS6paJPKDOb	2729381896189388167	gl-go/1.25.0-20250216-RC00 gccl/1.73.0 gapic/1.73.0 gax/2.14.1 grpc/1.69.2	us-central1	PRIORITY_HIGH	READ_WRITE
2025-05-20T03:31:52.591212Z	6561582859583559006	SELECT a.SingerId, a.AlbumId, a.TrackId, a.SongName, s.FirstName, s.LastName FROM Songs as a JOIN Singers as s ON s.SingerId = a.SingerId WHERE a.SingerId > 10 LIMIT 1000000;	FALSE	AG46FS7Pb_9H6J6p	9125776389780080794	gl-go/1.25.0-20250216-RC00 gccl/1.73.0 gapic/1.73.0 gax/2.14.1 grpc/1.69.2	us-central1	PRIORITY_LOW	READ_ONLY

Répertorier les 2 premières requêtes en cours les plus anciennes

Petite variante de la requête précédente, cet exemple renvoie les deux premières requêtes en cours les plus anciennes triées selon l'heure de début de la requête.

SELECT start_time,
       text_fingerprint,
       text,
       text_truncated,
       session_id
FROM spanner_sys.oldest_active_queries
ORDER BY start_time ASC LIMIT 2;

Sortie de la requête

Le tableau suivant présente le résultat de l'exécution de la requête mentionnée précédemment :

start_time	text_fingerprint	text	text_truncated	session_id
2039-07-18T07:52:28.225877Z	-3426560921851907385	SELECT a.SingerId, a.AlbumId, a.TrackId, b.SingerId as b_id, b.AlbumId as b_albumid, b.TrackId as b_trackId FROM Songs as a CROSS JOIN Songs as b;	Faux	ACjbPvYsuRt
2039-07-18T07:54:08.622081Z	-9206690983832919848	SELECT a.SingerId, a.AlbumId, a.TrackId, a.SongName, s.FirstName, s.LastName FROM Songs as a JOIN Singers as s ON s.SingerId = a.SingerId WHERE STARTS_WITH(s.FirstName, 'FirstName') LIMIT 1000000;	Faux	ACjbPvaF3yK

ACTIVE_QUERIES_SUMMARY

Le tableau de statistiques SPANNER_SYS.ACTIVE_QUERIES_SUMMARY affiche des statistiques récapitulatives pour toutes les requêtes actives. Les requêtes sont regroupées dans les catégories suivantes :

• datant de plus d'une seconde
• plus anciennes que 10 secondes ;
• plus de 100 secondes

Schéma de la table pour ACTIVE_QUERIES_SUMMARY

Nom de la colonne	Type	Description
ACTIVE_COUNT	INT64	Nombre total de requêtes en cours d'exécution.
OLDEST_START_TIME	TIMESTAMP	Limite supérieure de l'heure de début de la requête en cours la plus ancienne.
COUNT_OLDER_THAN_1S	INT64	Nombre de requêtes de plus d'une seconde.
COUNT_OLDER_THAN_10S	INT64	Nombre de requêtes de plus de 10 secondes.
COUNT_OLDER_THAN_100S	INT64	Nombre de requêtes de plus de 100 secondes.

Une requête peut être comptabilisée dans plusieurs de ces buckets. Par exemple, si une requête a été exécutée pendant 12 secondes, elle est comptabilisée dans COUNT_OLDER_THAN_1S et COUNT_OLDER_THAN_10S, car elle remplit les deux critères.

Exemples de requêtes

Vous pouvez exécuter les exemples d'instructions SQL suivants à l'aide des bibliothèques clientes, de gcloud spanner ou de la consoleGoogle Cloud .

Récupérer un résumé des requêtes actives

La requête suivante renvoie des statistiques récapitulatives sur les requêtes en cours.

SELECT active_count,
       oldest_start_time,
       count_older_than_1s,
       count_older_than_10s,
       count_older_than_100s
FROM spanner_sys.active_queries_summary;

Sortie de la requête

active_count	oldest_start_time	count_older_than_1s	count_older_than_10s	count_older_than_100s
22	2039-07-18T07:52:28.225877Z	21	21	1

Limites

Bien que l'objectif soit de vous fournir les insights les plus complets possibles, il existe des cas où les requêtes ne sont pas incluses dans les données renvoyées dans ces tables.

• Les requêtes LMD (UPDATE, INSERT, DELETE) ne sont pas incluses si elles se trouvent dans la phase Apply mutations.

• Une requête n'est pas incluse si elle est en cours de redémarrage en raison d'une erreur temporaire.

• Les requêtes provenant de serveurs surchargés ou qui ne répondent pas ne sont pas prises en compte.

• La lecture ou l'interrogation de la table OLDEST_ACTIVE_QUERIES ne peuvent pas être effectuées dans une transaction en lecture/écriture. Même dans une transaction en lecture seule, l'horodatage de la transaction est ignoré et elle renvoie toujours les données actuelles au moment de son exécution. Dans de rares cas, elle peut renvoyer une erreur ABORTED avec des résultats partiels. Dans ce cas, supprimez les résultats partiels et relancez la requête.

• Si la colonne CLIENT_IP_ADDRESS renvoie une chaîne <error>, cela indique un problème temporaire qui ne devrait pas affecter le reste de la requête. Réessayez d'exécuter la requête pour récupérer l'adresse IP du client.

Utiliser les données des requêtes actives pour résoudre les problèmes d'utilisation élevée du processeur

Les statistiques des requêtes et les statistiques de transactions fournissent des informations utiles lors de la résolution de problèmes de latence dans une base de données Spanner. Ces outils fournissent des informations sur les requêtes déjà terminées. Cependant, il est parfois nécessaire de savoir ce qui est en cours d'exécution dans le système. Par exemple, considérons le scénario suivant lequel l'utilisation du processeur est assez élevée et vous souhaitez répondre aux questions suivantes.

• Combien de requêtes sont exécutées actuellement ?
• Quelles sont ces requêtes ?
• Combien de requêtes sont exécutées pendant une longue période, autrement dit plus de 100 secondes ?
• Quelle session exécute la requête ?

Avec les réponses aux questions précédentes, vous pouvez décider d'effectuer l'action suivante.

• Supprimer la session qui exécute la requête pour une résolution immédiate.
• Améliorer les performances des requêtes en ajoutant un index.
• Réduisez la fréquence de la requête si elle est associée à une tâche d'arrière-plan périodique.
• Identifier l'utilisateur ou le composant qui émet la requête, et qui peut ne pas être autorisé à exécuter la requête.

Dans ce tutoriel, nous allons examiner nos requêtes actives et déterminer les mesures à prendre, le cas échéant.

Récupérer un résumé des requêtes actives

Dans notre exemple de scénario, nous constatons que l'utilisation du processeur est supérieure à la normale. Nous allons donc exécuter la requête suivante pour renvoyer un résumé des requêtes actives.

SELECT active_count,
       oldest_start_time,
       count_older_than_1s,
       count_older_than_10s,
       count_older_than_100s
FROM spanner_sys.active_queries_summary;

La requête donne les résultats suivants.

active_count	oldest_start_time	count_older_than_1s	count_older_than_10s	count_older_than_100s
22	2039-07-18T07:52:28.225877Z	21	21	1

Il semble qu'une seule requête en cours s'exécute pendant plus de 100 secondes. Ce résultat est inhabituel pour notre base de données et nous souhaitons l'étudier plus en détail.

Récupérer une liste de requêtes actives

Nous avons déterminé lors de l'étape précédente que nous exécutions une requête pendant plus de 100 secondes. Pour aller plus loin, nous exécutons la requête suivante pour renvoyer des informations supplémentaires sur les cinq requêtes en cours les plus anciennes.

SELECT start_time,
       text_fingerprint,
       text,
       text_truncated,
       session_id,
       query_id
FROM spanner_sys.oldest_active_queries
ORDER BY start_time ASC LIMIT 5;

Dans cet exemple, nous avons exécuté la requête le 28 mars 2024 à environ 16h44m09s EDT et récupéré les résultats suivants. (Vous devrez peut-être faire défiler la page horizontalement pour voir l'intégralité du résultat.)

start_time	text_fingerprint	text	text_truncated	session_id	query_id
2024-03-28 16:44:09.356939+00:00	-2833175298673875968	select * from spanner_sys.oldest_active_queries	faux	ACjbPvYsucrtcffHrRK6aObeIjZf12tSUwOsim-g1WC3IhqF4epzICCQR3GCHw	37190103859320827
2039-07-18T07:52:28.225877Z	-3426560921851907385	SELECT a.SingerId, a.AlbumId, a.TrackId, b.SingerId as b_id, b.AlbumId as b_albumid, b.TrackId as b_trackId FROM Songs as a CROSS JOIN Songs as b;	faux	ACjbPvaF3yKiNfxXFod2LPoFaXjKR759Bw1o34206vv0t7eOrD3wxZhu8U6ohQ	48946620525959556

La requête la plus ancienne (empreinte = -2833175298673875968) est mise en surbrillance dans le tableau. Le service est cher. CROSS JOIN. Nous décidons d'agir.

Annuler une requête coûteuse

Dans cet exemple, nous avons trouvé une requête exécutant une jointure croisée CROSS JOIN coûteuse. Nous décidons donc de l'annuler. Les résultats de la requête que nous avons reçus à l'étape précédente comprenaient un query_id. Nous pouvons exécuter la commande CALL cancel_query(query_id) suivante pour GoogleSQL et la commande spanner.cancel_query(query_id) pour PostgreSQL afin d'annuler la requête.

GoogleSQL

CALL cancel_query(query_id)

PostgreSQL

CALL spanner.cancel_query(query_id)

Par exemple, dans l'exemple suivant, l'instruction CALL annule une requête avec l'ID 37190103859320827 :

CALL cancel_query('37190103859320827')

Remarque : Dans Spanner, l'opération CALL n'est compatible qu'avec l'appel de procédure cancel_query. Pour en savoir plus sur les procédures stockées, consultez la page Procédures stockées (GoogleSQL ou PostgreSQL).

Vous devez interroger la table spanner_sys.oldest_active_queries pour vérifier que la requête a été annulée.

Remarque : CALL cancel_query est une opération effectuée dans la mesure du possible. Il est possible qu'il n'annule pas une requête lorsque les serveurs Spanner sont occupés en raison de charges de requêtes importantes. Si cela se produit, essayez d'exécuter CALL cancel_query une deuxième fois.

Ce tutoriel explique comment utiliser SPANNER_SYS.OLDEST_ACTIVE_QUERIES et SPANNER_SYS.ACTIVE_QUERIES_SUMMARY pour analyser nos requêtes en cours d'exécution et prendre les mesures nécessaires, le cas échéant, sur toute requête contribuant à une utilisation intensive du processeur. Évidemment, il est toujours plus économique d'éviter les opérations coûteuses et de concevoir un schéma adapté à vos cas d'utilisation. Pour en savoir plus sur la construction d'instructions SQL qui s'exécutent efficacement, consultez la section Bonnes pratiques SQL.

Étape suivante

• Découvrez d'autres outils d'introspection.
• Découvrez les autres informations stockées par Spanner pour chaque base de données dans les tables du schéma d'informations de cette base de données.
• Explorez les bonnes pratiques SQL relatives à Spanner.