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 pour le préchargement et d'autres frais généraux.

  • 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èmes de mise en réseau internes, certaines statistiques peuvent passer inaperçues.

Qui peut en bénéficier ?

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 avec 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 de tous les serveurs, puis les met à disposition dans les tables SPANNER_SYS peu de temps après.

    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 des statistiques pour toutes les exécutions d'une forme de lecture particulière pour laquelle Spanner enregistre des statistiques pendant l'intervalle spécifié.

  • Si Spanner ne peut pas stocker d'informations sur chaque forme de lecture distincte exécutée pendant l'intervalle, le système donne la priorité aux formes de lecture ayant la plus forte utilisation 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 une PARTITIONED_READ ou une READ. Une lecture avec un jeton de partition obtenu à partir de l'API PartitionRead est représentée par 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 pendant 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 de processeur côté serveur Spanner exécutant la lecture, à l'exclusion du processeur de préchargement et d'autres frais généraux.
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 pourrait 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 vers 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 des bibliothèques clientes, de gcloud spanner ou de la 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 permettant de stocker les statistiques de lecture agrégées capturées par Spanner sur une période spécifique:

  • 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 se terminent toutes les 10 minutes à partir de l'heure et les intervalles d'une heure se terminent 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 des formes de lecture que Spanner n'a pas capturées dans les tables SPANNER_SYS.READ_STATS_TOP_*.

  • Certaines colonnes de ces tables sont exposées sous forme de 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 de la variante optimale
    • 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 de fois où Spanner a exécuté la forme de lecture pendant 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 de processeur côté serveur Spanner exécutant la lecture, à l'exclusion du processeur de préchargement et d'autres frais généraux.
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 lectures 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 au minimum les données de chaque table pour les périodes suivantes:

  • 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 intensive du processeur avec les statistiques de lecture

Les statistiques de lecture Spanner sont utiles lorsque vous devez étudier une utilisation intensive du processeur sur votre base de données Spanner ou lorsque vous essayez simplement de comprendre les formes de lecture utilisant beaucoup de processeurs sur votre base de données. L'inspection des formes de lecture qui utilisent des quantités importantes de ressources de base de données permet aux utilisateurs de Spanner de réduire les coûts opérationnels et d'améliorer 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 a commencé à se produire vers 17h20 le 28 mai 2020.

Recueillir 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 intensive 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 intensive du processeur

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

  • Le nombre de fois où Spanner a exécuté des formes de lecture pendant l'intervalle est un bon exemple de métrique qui a besoin d'une référence pour vous indiquer si une mesure est raisonnable ou est le signe d'un problème. 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.

  • Exécutez la requête suivante pour rechercher les principales formes de lecture classées en fonction du 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 basses possibles, en particulier lorsque vous utilisez des configurations d'instances multirégionales, utilisez des lectures non actualisées au lieu de 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. Les lectures uniques ne se verrouillent pas, contrairement aux transactions en lecture-écriture. Vous devez donc utiliser des transactions en lecture seule plutôt que des transactions en lecture-écriture plus coûteuses lorsque vous n'écrivez pas de données.

Étapes suivantes