Lire les statistiques

Spanner fournit des tables intégrées qui stockent des statistiques sur les lectures. Vous pouvez récupérer les statistiques de ces tables SPANNER_SYS.READ_STATS* à l'aide d'instructions SQL.

Dans quels cas utiliser les statistiques de lecture

Les statistiques de lecture fournissent des informations sur l'utilisation d'une base de données par une application. Elles sont utiles pour analyser les problèmes de performances. Par exemple, vous pouvez vérifier les formes de lecture qui s'exécutent sur une base de données, leur fréquence d'exécution et les caractéristiques de performance de ces formes de lecture. Vous pouvez utiliser les statistiques de lecture de votre base de données pour identifier les formes de lecture qui suscitent une utilisation intensive du processeur. De manière générale, les statistiques de lecture vous aideront à comprendre le comportement du trafic entrant dans une base de données en termes d'utilisation des ressources.

Limites

  • Cet outil est particulièrement adapté à l'analyse des flux de lectures similaires qui représentent la majorité de l'utilisation du processeur. Il ne convient pas pour rechercher des lectures n'ayant été exécutées qu'une seule fois.

  • L'utilisation du processeur suivie dans ces statistiques représente l'utilisation du processeur côté serveur de Spanner, à l'exclusion de l'utilisation du processeur de préchargement et d'autres surcharges supplémentaires.

  • Les statistiques sont collectées de la manière la plus optimale possible. Par conséquent, il est possible que les statistiques soient oubliées en cas de problèmes liés à des systèmes sous-jacents. Par exemple, en cas de problème lié au réseau interne, il est possible que certaines statistiques ne soient pas prises en compte.

Disponibilité

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

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

  • La commande gcloud spanner databases execute-sql

  • L'API executeQuery

Les autres méthodes de lecture unique fournies par Spanner ne sont pas compatibles SPANNER_SYS

Utilisation du processeur regroupée par forme de lecture

Les tables ci-dessous suivent les formes de lecture ayant entraîné le plus haut niveau d'utilisation du processeur pendant une période donnée :

  • SPANNER_SYS.READ_STATS_TOP_MINUTE : statistiques de forme de lecture globales sur des intervalles d'une minute.
  • SPANNER_SYS.READ_STATS_TOP_10MINUTE : statistiques de forme de lecture globales sur des intervalles de 10 minutes.
  • SPANNER_SYS.READ_STATS_TOP_HOUR : statistiques de forme de lecture globales sur des intervalles d'une heure.

Ces tables ont les propriétés suivantes :

  • Chaque table contient les données correspondant à des intervalles de temps sans chevauchement de la durée spécifiée par le nom de la table.

  • Les intervalles sont définis selon l'heure réelle. Les intervalles d'une minute se terminent toutes les minutes, les intervalles de 10 minutes s'achèvent toutes les 10 minutes à partir de l'heure juste, et les intervalles d'une heure prennent fin toutes les heures. Après chaque intervalle, Spanner collecte les données serveurs, puis rend les données disponibles dans les tables SPANNER_SYS sous peu par la suite.

    Par exemple, à 11:59:30, les intervalles les plus récents disponibles pour les requêtes SQL sont les suivants :

    • 1 minute : 11:58:00 – 11:58:59
    • 10 minutes : 11:40:00 – 11:49:59
    • 1 heure : 10:00:00 – 10:59:59

  • Spanner regroupe les statistiques par forme de lecture. Si une balise est présente, FPRINT correspond au hachage de la balise. Sinon, il s'agit du hachage de la valeur READ_COLUMNS.

  • Chaque ligne contient les statistiques correspondant à toutes les exécutions d'une forme de lecture donnée pour laquelle Spanner enregistre des statistiques pendant l'intervalle spécifié.

  • Si Spanner n'est pas en mesure de stocker des informations sur chaque lecture distincte de forme exécutée pendant l'intervalle, le système donne la priorité aux formes lues avec le paramètre l'utilisation la plus élevée du processeur pendant l'intervalle spécifié.

Schéma de la table

Nom de la colonne Type Description
INTERVAL_END TIMESTAMP Fin de l'intervalle de temps au cours duquel les exécutions de lecture retenues ont eu lieu.
REQUEST_TAG STRING Tag de requête facultatif pour cette opération de lecture. Pour en savoir plus sur l'utilisation des tags, consultez la page Résoudre les problèmes liés aux tags de requête. Les statistiques de plusieurs lectures ayant la même chaîne de tag sont regroupées sur une seule ligne avec le "REQUEST_TAG" correspondant à cette chaîne de tag.
READ_TYPE STRING Indique si une lecture est un PARTITIONED_READ ou READ Une lecture avec partitionToken obtenu à partir de l'API PartitionRead est représenté par le le type de lecture PARTITIONED_READ et les autres API de lecture par READ
READ_COLUMNS ARRAY<STRING> Ensemble de colonnes lues. Classées par ordre alphabétique.
FPRINT INT64 Hachage de la valeur REQUEST_TAG, le cas échéant. Dans le cas contraire, hachage de la valeur READ_COLUMNS.
EXECUTION_COUNT INT64 Nombre de fois où Spanner a exécuté la forme de lecture au cours de la l'intervalle.
AVG_ROWS FLOAT64 Nombre moyen de lignes renvoyées par la lecture.
AVG_BYTES FLOAT64 Nombre moyen d'octets de données renvoyés par la lecture, à l'exclusion de la surcharge liée à l'encodage de la transmission.
AVG_CPU_SECONDS FLOAT64 Nombre moyen de secondes du processeur côté serveur Spanner exécutant la lecture, à l'exclusion du processeur de préchargement et d'autres surcharges.
AVG_LOCKING_DELAY_SECONDS FLOAT64 Nombre moyen de secondes passées à attendre en raison du verrouillage.
AVG_CLIENT_WAIT_SECONDS FLOAT64 Nombre moyen de secondes passées à attendre, car le client ne consomme pas les données aussi rapidement que Spanner peut les générer.
AVG_LEADER_REFRESH_DELAY_SECONDS FLOAT64 Nombre moyen de secondes passées à attendre la confirmation, avec le leader Paxos, que toutes les écritures ont été observées.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Nombre de fois où la lecture a été exécutée dans le cadre d'une transaction en lecture/écriture. Cette colonne vous aide à déterminer si vous pouvez éviter les conflits de verrouillage en déplaçant la lecture à une transaction en lecture seule.

Exemples de requêtes

Cette section présente plusieurs exemples d'instructions SQL permettant d'extraire des statistiques de lecture. Vous pouvez exécuter ces instructions SQL à l'aide du bibliothèques clientes, gcloud spanner ou Console Google Cloud :

Répertorier les statistiques de base relatives à chaque forme de lecture sur une période donnée

La requête suivante renvoie les données brutes correspondant aux principales formes de lecture exécutées dans les intervalles d'une minute les plus récents.

SELECT fprint,
       read_columns,
       execution_count,
       avg_cpu_seconds,
       avg_rows,
       avg_bytes,
       avg_locking_delay_seconds,
       avg_client_wait_seconds
FROM spanner_sys.read_stats_top_minute
ORDER BY interval_end DESC LIMIT 3;
Sortie de la requête
fprint read_columns execution_count avg_cpu_seconds avg_rows avg_bytes avg_locking_delay_seconds avg_client_wait_seconds
125062082139 ["Singers.id", "Singers.name"] 8514387 0.000661355290396507 310.79 205 8.3232564943763752e-06 0
151238888745 ["Singers.singerinfo"] 3341542 6.5992827184280315e-05 12784 54 4.6859741349028595e-07 0
14105484 ["Albums.id", "Albums.title"] 9306619 0.00017855774721667873 1165.4 2964.71875 1.4328191393074178e-06 0

Répertorier les formes de lecture, triées en fonction du plus haut niveau d'utilisation totale du processeur

La requête suivante renvoie les formes de lecture avec le plus haut niveau d'utilisation du processeur au cours de l'heure la plus récente :

SELECT read_columns,
       execution_count,
       avg_cpu_seconds,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.read_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.read_stats_top_hour)
ORDER BY total_cpu DESC LIMIT 3;
Sortie de la requête
read_columns execution_count avg_cpu_seconds total_cpu
["Singers.id", "Singers.name"] 1647 0.00023380297430622681 0.2579
["Albums.id", "Albums.title"] 720 0.00016738889440282034 0.221314999999999
["Singers.singerinfo""] 3223 0.00037764625882302246 0.188053

Statistiques globales

SPANNER_SYS contient également des tables pour stocker les statistiques de lecture agrégées capturées par Spanner sur une période donnée:

  • SPANNER_SYS.READ_STATS_TOTAL_MINUTE : statistiques globales pour toutes les formes de lecture pendant des intervalles d'une minute.
  • SPANNER_SYS.READ_STATS_TOTAL_10MINUTE : statistiques globales pour toutes les formes de lecture pendant des intervalles de 10 minutes.
  • SPANNER_SYS.READ_STATS_TOTAL_HOUR : statistiques globales pour toutes les formes de lecture pendant des intervalles d'une heure.

Les tableaux de statistiques globales présentent les propriétés suivantes :

  • Chaque table contient les données correspondant à des intervalles de temps sans chevauchement de la durée spécifiée par le nom de la table.

  • Les intervalles sont définis selon l'heure réelle. Les intervalles d'une minute se terminent toutes les minutes, les intervalles de 10 minutes s'achèvent toutes les 10 minutes à partir de l'heure juste, et les intervalles d'une heure prennent fin toutes les heures.

    Par exemple, à 11:59:30, les intervalles les plus récents disponibles pour les requêtes SQL sur les statistiques de lecture globales sont les suivants :

    • 1 minute : 11:58:00 – 11:58:59
    • 10 minutes : 11:40:00 – 11:49:59
    • 1 heure : 10:00:00 – 10:59:59

  • Chaque ligne contient les statistiques globales correspondant à l'ensemble des formes de lecture exécutées sur la base de données au cours de l'intervalle spécifié. Il n'y a par conséquent qu'une seule ligne par intervalle de temps.

  • Les statistiques capturées dans les tables SPANNER_SYS.READ_STATS_TOTAL_* peuvent inclure les formes de lecture que Spanner n'a pas capturées SPANNER_SYS.READ_STATS_TOP_* tables.

  • Certaines colonnes de ces tables sont présentées en tant que métriques dans Cloud Monitoring. Les métriques exposées sont les suivantes:

    • Nombre de lignes renvoyées
    • Nombre d'exécutions de lecture
    • Lire le temps CPU
    • Retards de verrouillage
    • Temps d'attente du client
    • Délai d'actualisation du leader
    • Nombre d'octets renvoyés

    Pour en savoir plus, consultez la page Métriques Spanner.

Schéma de la table

Nom de la colonne Type Description
INTERVAL_END TIMESTAMP Fin de l'intervalle de temps au cours duquel les exécutions de formes de lecture retenues ont eu lieu.
EXECUTION_COUNT INT64 Nombre d'exécutions de la forme de lecture par Spanner au cours de l'intervalle.
AVG_ROWS FLOAT64 Nombre moyen de lignes renvoyées par les lectures.
AVG_BYTES FLOAT64 Nombre moyen d'octets de données renvoyés par les lectures, à l'exclusion de la surcharge liée à l'encodage de la transmission
AVG_CPU_SECONDS FLOAT64 Nombre moyen de secondes du processeur côté serveur Spanner exécutant la lecture, à l'exclusion du processeur de préchargement et d'autres surcharges.
AVG_LOCKING_DELAY_SECONDS FLOAT64 Nombre moyen de secondes passées à attendre en raison du verrouillage.
AVG_CLIENT_WAIT_SECONDS FLOAT64 Nombre moyen de secondes passées à attendre en raison de la limitation.
AVG_LEADER_REFRESH_DELAY_SECONDS FLOAT64 Nombre moyen de secondes passées à coordonner les lectures entre instances dans des configurations multirégionales.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Nombre de fois où des lectures ont été exécutées dans le cadre de transactions en lecture/écriture. Cette colonne vous aide à déterminer si vous pouvez éviter les conflits de verrouillage en déplaçant certaines lectures vers des transactions en lecture seule.

Exemples de requêtes

Cette section présente plusieurs exemples d'instructions SQL permettant d'extraire des statistiques de lecture globales. Vous pouvez exécuter ces instructions SQL à l'aide des bibliothèques clientes, de gcloud spanner ou de la console Google Cloud.

Déterminer l'utilisation totale du processeur pour toutes les formes de lecture

La requête suivante renvoie le nombre d'heures de processeur consommées par les formes de lecture au cours de la dernière heure :

SELECT (avg_cpu_seconds * execution_count / 60 / 60)
  AS total_cpu_hours
FROM spanner_sys.read_stats_total_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.read_stats_total_hour);
Sortie de la requête
total_cpu_hours
0.00026186111111111115

Déterminer le nombre total d'exécutions pour une période donnée

La requête suivante renvoie le nombre total de formes de lecture exécutées dans l'intervalle complet d'une minute le plus récent :

SELECT interval_end,
       execution_count
FROM spanner_sys.read_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.read_stats_total_minute);
Sortie de la requête
interval_end execution_count
2020-05-28 11:02:00-07:00 12861966

Conservation des données

Spanner conserve les données de chaque table pendant une durée minimale variable selon le type de table :

  • SPANNER_SYS.READ_STATS_TOP_MINUTE et SPANNER_SYS.READ_STATS_TOTAL_MINUTE : intervalles couvrant les six heures précédentes

  • SPANNER_SYS.READ_STATS_TOP_10MINUTE et SPANNER_SYS.READ_STATS_TOTAL_10MINUTE : intervalles couvrant les quatre derniers jours.

  • SPANNER_SYS.READ_STATS_TOP_HOUR et SPANNER_SYS.READ_STATS_TOTAL_HOUR : intervalles couvrant les 30 derniers jours.

Résoudre les problèmes d'utilisation élevée du processeur à l'aide des statistiques de lecture

Les statistiques de lecture Spanner sont utiles lorsque vous devez analyser l'utilisation élevée du processeur dans votre base de données Spanner ou lorsque vous essayez simplement de comprendre les formes de lecture qui utilisent un processeur de manière intensive sur votre base de données. L'inspection des formes de lecture qui utilisent d'importantes quantités de ressources de base de données permet aux utilisateurs de Spanner de réduire les coûts opérationnels et d'améliorer éventuellement les latences générales du système. Les étapes suivantes vous expliquent comment utiliser les statistiques de lecture pour analyser l'utilisation élevée du processeur dans votre base de données.

Sélectionnez une période à examiner

Commencez votre évaluation en recherchant une heure à laquelle votre application a commencé à subir une utilisation élevée du processeur. Par exemple, dans le scénario suivant, le problème est survenu vers 17h20, le 28 mai 2020.

Collecter les statistiques de lecture pour la période sélectionnée

Après avoir sélectionné une période pour démarrer notre enquête, nous examinerons les statistiques collectées dans la table READ_STATS_TOTAL_10MINUTE autour de cette période. Les résultats de cette requête peuvent nous donner des indications sur la manière dont les statistiques du processeur et autres statistiques de lecture ont évolué au cours de cette période. La requête suivante renvoie les statistiques de lecture agrégées de 4:30 pm à 7:30 pm (inclus).

SELECT
  interval_end,
  ROUND(avg_cpu_seconds,4) as avg_cpu_seconds,
  execution_count,
  avg_locking_delay_seconds
FROM SPANNER_SYS.READ_STATS_TOTAL_10MINUTE
WHERE
  interval_end >= "2020-05-28T16:30:00"
  AND interval_end <= "2020-05-28T19:30:00"
ORDER BY interval_end;

Les données suivantes sont un exemple du résultat que nous obtenons de notre requête.

interval_end avg_cpu_seconds execution_count avg_locking_delay_seconds
2020-05-28 16:40:00-07:00 0.0004 11111421 8.3232564943763752e-06
2020-05-28 16:50:00-07:00 0.0002 8815637 8.98734051776406e-05
2020-05-28 17:00:00-07:00 0.0001 8260215 6.039129247846453e-06
2020-05-28 17:10:00-07:00 0.0001 8514387 9.0535466616680686e-07
2020-05-28 17:20:00-07:00 0.0006 13715466 2.6801485272173765e-06
2020-05-28 17:30:00-07:00 0.0007 12861966 4.6859741349028595e-07
2020-05-28 17:40:00-07:00 0.0007 3755954 2.7131391918005383e-06
2020-05-28 17:50:00-07:00 0.0006 4248137 1.4328191393074178e-06
2020-05-28 18:00:00-07:00 0.0006 3986198 2.6973481999639748e-06
2020-05-28 18:10:00-07:00 0.0006 3510249 3.7577083563017905e-06
2020-05-28 18:20:00-07:00 0.0004 3341542 4.0940589703795433e-07
2020-05-28 18:30:00-07:00 0.0002 8695147 1.9914494947583975e-05
2020-05-28 18:40:00-07:00 0.0003 11679702 1.8331461539001595e-05
2020-05-28 18:50:00-07:00 0.0003 9306619 1.2527332321222135e-05
2020-05-28 19:00:00-07:00 0.0002 8520508 6.2268448078447915e-06
2020-05-28 19:10:00-07:00 0.0006 13715466 2.6801485272173765e-06
2020-05-28 19:20:00-07:00 0.0005 11947323 3.3029114639321295e-05
2020-05-28 19:30:00-07:00 0.0002 8514387 9.0535466616680686e-07

Ici, nous constatons que le temps CPU moyen (avg_cpu_seconds) est plus élevé dans les intervalles mis en surbrillance. Le paramètre interval_end présentant la valeur 2020-05-28 19:20:00 présente un temps CPU plus élevé. Nous allons donc choisir cet intervalle pour réaliser un examen plus approfondi.

Identifier les formes de lecture qui entraînent une utilisation élevée du processeur

Pour aller un peu plus loin, nous allons maintenant interroger la table READ_STATS_TOP_10MINUTE pour l'intervalle sélectionné à l'étape précédente. Les résultats de cette requête peuvent aider à indiquer les formes de lecture qui entraînent une utilisation élevée du processeur.

SELECT
  read_columns,
  ROUND(avg_cpu_seconds,4) as avg_cpu_seconds,
  execution_count,
  avg_rows
FROM SPANNER_SYS.READ_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-28T19:20:00"
ORDER BY avg_cpu_seconds DESC LIMIT 3;

Les données suivantes constituent un exemple du résultat obtenu à la suite de notre requête, renvoyant des informations sur les trois principales formes de lecture classées par avg_cpu_seconds. Notez l'utilisation de ROUND dans notre requête pour limiter la sortie de avg_cpu_seconds à 4 décimales.

read_columns avg_cpu_seconds execution_count avg_rows
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares]1 0.4192 1182 11650.42216582
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score] 0.0852 4 12784
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount] 0.0697 1140 310.7921052631

1 _exists est un champ interne utilisé pour vérifier si une ligne existe ou non.

L'utilisation élevée du processeur peut être due à l'exécution plus fréquente de formes de lecture (execution_count). Le nombre moyen de lignes renvoyées par la lecture a peut-être augmenté (avg_rows). Si aucune de ces propriétés de la forme de lecture ne révèle quelque chose d'intéressant, vous pouvez examiner d'autres propriétés, telles que avg_locking_delay_seconds, avg_client_wait_seconds ou avg_bytes.

Appliquer les bonnes pratiques pour réduire l'utilisation élevée du processeur

Lorsque vous avez terminé les étapes précédentes, déterminez si l'une de ces bonnes pratiques peut vous aider.

  • Parmi les bons exemples de métrique nécessitant une référence pour vous indiquer si une mesure est raisonnable ou plutôt synonyme de problème, l'on retrouve le nombre d'exécutions des formes de lecture par Spanner pendant l'intervalle. Après avoir établi une référence pour la métrique, vous pourrez détecter et examiner la cause d'écarts inattendus par rapport au comportement normal.

  • Si l'utilisation du processeur est relativement constante, mais montre soudainement un pic pouvant être mis en corrélation avec un pic soudain de demandes d'utilisateurs ou de comportement d'application, cela peut indiquer que tout fonctionne comme prévu.

  • Essayez la requête suivante pour trouver les formes de lecture les plus classées par nombre de nombre d'exécutions de Spanner pour chaque forme de lecture:

    SELECT interval_end, read_columns, execution_count
FROM SPANNER_SYS.READ_STATS_TOP_MINUTE
ORDER BY execution_count DESC
LIMIT 10;

  • Si vous recherchez les latences de lecture les plus faibles possibles, en particulier lors de l'utilisation de configurations d'instances multirégionales, utilisez des lectures non actualisées plutôt que des lectures fortes pour réduire ou supprimer le composant AVG_LEADER_REFRESH_DELAY_SECONDS de la latence de lecture.

  • Si vous n'effectuez que des lectures et que vous pouvez les exprimer à l'aide d'une méthode de lecture unique, utilisez cette méthode. Contrairement aux transactions en lecture-écriture, les lectures uniques ne se verrouillent pas. Par conséquent, lorsque vous n'écrivez pas de données, il est donc recommandé d'utiliser des transactions en lecture seule plutôt que des transactions en lecture-écriture plus coûteuses.

Étape suivante