Statistiques de transaction

Ce document décrit les statistiques de transaction que Spanner propose sous forme de tables intégrées. Vous pouvez récupérer les statistiques de ces tables SPANNER_SYS.TXN_STATS* à l'aide d'instructions SQL.

Quand utiliser les statistiques sur les transactions ?

Les statistiques sur les transactions sont utiles pour analyser les problèmes de performances. Par exemple, vous pouvez vérifier s'il existe des transactions lentes qui pourraient avoir un impact sur les performances ou le nombre de requêtes par seconde (RPS) dans votre base de données. Un autre scénario est celui où vos applications clientes connaissent une latence d'exécution des transactions élevée. L'analyse des statistiques de transaction peut aider à découvrir d'éventuels goulots d'étranglement, tels que des volumes importants de mises à jour d'une colonne particulière, qui pourraient avoir un impact sur la latence.

Accéder aux statistiques sur les transactions

Spanner fournit les statistiques de transaction de table dans le schéma SPANNER_SYS. Vous pouvez utiliser les méthodes suivantes pour accéder aux données SPANNER_SYS :

Les méthodes de lecture unique suivantes fournies par Spanner ne sont pas compatibles avec SPANNER_SYS :

  • 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 de latence regroupées par transaction

Les tableaux suivants permettent d'effectuer le suivi des statistiques des transactions TOP consommant des ressources au cours d'une période donnée.

  • SPANNER_SYS.TXN_STATS_TOP_MINUTE : statistiques de transaction agrégées sur des intervalles d'une minute.

  • SPANNER_SYS.TXN_STATS_TOP_10MINUTE : statistiques de transaction agrégées par intervalles de 10 minutes.

  • SPANNER_SYS.TXN_STATS_TOP_HOUR : statistiques de transaction agrégées sur des intervalles d'une heure.

Ces tables ont les propriétés suivantes :

  • Chaque table contient des données pour des intervalles de temps qui ne se chevauchent pas et dont la durée est spécifiée par le nom de la table.

  • Les intervalles sont basés sur les heures de l'horloge

    • Les intervalles d'une minute se terminent à la minute.
    • Les intervalles de 10 minutes se terminent toutes les 10 minutes à partir de l'heure pile.
    • Les intervalles d'une heure se terminent à l'heure pile.

    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 FPRINT (empreinte) des transactions. Si un tag de transaction est présent, FPRINT est le hachage du tag. Sinon, il s'agit du hachage calculé en fonction des opérations impliquées dans la transaction.

  • Étant donné que les statistiques sont regroupées en fonction de FPRINT, si la même transaction est exécutée plusieurs fois au cours d'un intervalle de temps, une seule entrée apparaît pour cette transaction dans ces tables.

  • Chaque ligne contient des statistiques pour toutes les exécutions d'une transaction particulière pour laquelle Spanner capture des statistiques pendant l'intervalle spécifié.

  • Si Spanner ne parvient pas à stocker les statistiques de toutes les transactions exécutées pendant l'intervalle dans ces tables, le système donne la priorité aux transactions présentant la latence, les tentatives de commit et les octets écrits les plus élevés pendant l'intervalle spécifié.

  • Toutes les colonnes des tables peuvent être nulles.

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 transaction retenues ont eu lieu.
TRANSACTION_TAG STRING Tag de transaction facultatif pour cette opération de transaction. Pour en savoir plus sur l'utilisation des tags, consultez Résoudre les problèmes à l'aide de tags de transaction. Les statistiques de plusieurs transactions ayant la même chaîne de tag sont regroupées sur une seule ligne, avec la valeur "TRANSACTION_TAG" correspondant à cette chaîne de tag.
FPRINT INT64 Hachage de TRANSACTION_TAG, le cas échéant. Dans le cas contraire, le hachage est calculé en fonction des opérations associées à la transaction. L'ensemble composé de INTERVAL_END et FPRINT constitue une clé unique pour ces tables.
READ_COLUMNS ARRAY<STRING> Ensemble de colonnes lues par la transaction.
WRITE_CONSTRUCTIVE_COLUMNS ARRAY<STRING> Ensemble de colonnes qui ont été écrites de manière constructive, c'est-à-dire auxquelles de nouvelles valeurs ont été attribuées par la transaction.

Pour les flux de modifications, si la transaction implique des écritures dans des colonnes et des tables surveillées par un flux de modifications, WRITE_CONSTRUCTIVE_COLUMNS contient deux colonnes : .data et ._exists, précédées d'un nom de flux de modifications. _exists est un champ utilisé pour vérifier si une ligne donnée existe ou non.
WRITE_DELETE_TABLES ARRAY<STRING> Ensemble de tables dont les lignes ont été supprimées ou remplacées par la transaction.
ATTEMPT_COUNT INT64 Nombre total de tentatives de transaction, y compris celles qui sont abandonnées avant l'appel de la méthode commit. Ce nombre représente le nombre total de tentatives au cours de l'intervalle spécifié. Pour en savoir plus sur les intervalles, consultez Intervalles.
COMMIT_ATTEMPT_COUNT INT64 Nombre total de tentatives de commit de transaction. Ce nombre doit correspondre au nombre d'appels à la méthode commit de la transaction. Ce nombre représente le nombre total de tentatives de commit au cours de l'intervalle spécifié. Pour en savoir plus sur les intervalles, consultez Intervalles.
COMMIT_ABORT_COUNT INT64 Nombre total de tentatives de transaction qui sont abandonnées, y compris celles qui sont abandonnées avant d'appeler la méthode commit de la transaction. Ce nombre représente le nombre total d'abandons au cours de l'intervalle spécifié. Pour en savoir plus sur les intervalles, consultez Intervalles.
COMMIT_RETRY_COUNT INT64 Nombre total de tentatives qui sont des nouvelles tentatives de tentatives précédemment abandonnées. Une transaction Spanner peut être tentée plusieurs fois avant d'être validée en raison de conflits de verrouillage ou d'événements temporaires. Un nombre élevé de nouvelles tentatives par rapport aux tentatives de commit indique qu'il peut y avoir des problèmes à examiner. Pour en savoir plus, consultez la section Comprendre les transactions et le nombre de commits sur cette page.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Nombre total de tentatives de commit de transaction ayant renvoyé des erreurs de condition préalable, telles que des violations d'index UNIQUE, des erreurs de type "ligne déjà existante" ou "ligne introuvable".
SERIALIZABLE_PESSIMISTIC_TXN_COUNT INT64 Nombre total de tentatives de transaction initiées avec le niveau d'isolation SERIALIZABLE et le verrouillage PESSIMISTIC. Il s'agit d'un sous-ensemble de ATTEMPT_COUNT.
SERIALIZABLE_OPTIMISTIC_TXN_COUNT INT64 Nombre total de tentatives de transaction initiées avec le niveau d'isolation SERIALIZABLE et le verrouillage OPTIMISTIC. Il s'agit d'un sous-ensemble de ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT INT64 Nombre total de tentatives de transaction initiées avec le niveau d'isolation REPEATABLE READ et le verrouillage OPTIMISTIC. Il s'agit d'un sous-ensemble de ATTEMPT_COUNT.
AVG_PARTICIPANTS FLOAT64 Nombre moyen de participants à chaque tentative de commit. Pour en savoir plus sur les participants, consultez Cycle de vie des lectures et écritures Spanner.
AVG_TOTAL_LATENCY_SECONDS FLOAT64 Nombre moyen de secondes écoulées entre la première opération de la transaction et le commit ou l'abandon.
AVG_COMMIT_LATENCY_SECONDS FLOAT64 Nombre moyen de secondes nécessaires pour effectuer l'opération de commit.
AVG_BYTES FLOAT64 Nombre moyen d'octets écrits par la transaction.
TOTAL_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogramme de la latence totale de commit, qui correspond au délai entre l'heure de début de la première opération transactionnelle et l'heure de commit ou d'abandon, pour toutes les tentatives d'une transaction.

Si une transaction est abandonnée plusieurs fois, puis validée, la latence est mesurée pour chaque tentative jusqu'à la validation finale. Les valeurs sont mesurées en secondes.

Le tableau contient un seul élément et est du type suivant :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Pour en savoir plus sur les valeurs, consultez Distribution et Exponentiel.

Pour calculer la latence du centile à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), qui renvoie le n-ième centile estimé. Pour obtenir un exemple associé, consultez Rechercher la latence au 99e centile pour les transactions.

Pour en savoir plus, consultez Centiles et métriques de distribution.

OPERATIONS_BY_TABLE ARRAY<STRUCT>

Impact des opérations INSERT ou UPDATE par la transaction sur une base par table. Cela est indiqué par le nombre de fois où les lignes sont affectées et le nombre d'octets écrits.

Cette colonne permet de visualiser la charge sur les tables et fournit des insights sur la vitesse à laquelle une transaction écrit dans les tables.

Spécifiez le tableau comme suit :
ARRAY<STRUCT<
  TABLE STRING(MAX),
  INSERT_OR_UPDATE_COUNT INT64,
  INSERT_OR_UPDATE_BYTES INT64>>

TOTAL_LATENCY_DISTRIBUTION_JSON_STRING STRING

Histogramme de la latence totale de commit, qui correspond au délai entre l'heure de début de la première opération transactionnelle et l'heure de commit ou d'abandon, pour toutes les tentatives d'une transaction.

Représentation sous forme de chaîne compatible JSON de la statistique TOTAL_LATENCY_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que la STRUCT définie dans TOTAL_LATENCY_DISTRIBUTION.

Si une transaction est abandonnée plusieurs fois, puis validée, la latence est mesurée pour chaque tentative jusqu'à la validation finale. Les valeurs sont mesurées en secondes.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL. Cette colonne contient la distribution.

Pour calculer la latence du centile à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), qui renvoie le n-ième centile estimé. Pour obtenir un exemple associé, consultez Rechercher la latence au 99e centile pour les transactions à l'aide de la colonne TOTAL_LATENCY_DISTRIBUTION_JSON_STRING.

Pour en savoir plus, consultez Centiles et métriques de distribution.

OPERATIONS_BY_TABLE_JSON_STRING STRING

Impact des opérations INSERT ou UPDATE par la transaction sur une base par table. Cela est indiqué par le nombre de fois où les lignes sont affectées et le nombre d'octets écrits.

Représentation sous forme de chaîne compatible JSON de la colonne OPERATIONS_BY_TABLE. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne OPERATIONS_BY_TABLE.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Cette colonne permet de visualiser la charge sur les tables et fournit des insights sur la vitesse à laquelle une transaction écrit dans les tables.

COMMIT_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogramme du nombre de secondes nécessaires pour effectuer l'opération de commit.

Le tableau présente la structure suivante :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Pour en savoir plus sur les types de valeurs, consultez Distribution et Exponentiel.

Pour calculer les centiles de latence de commit à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

COMMIT_LATENCY_DISTRIBUTION_JSON_STRING STRING

Représentation sous forme de chaîne compatible JSON de la statistique COMMIT_LATENCY_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne COMMIT_LATENCY_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Pour calculer les centiles de latence de commit à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

PARTICIPANTS_DISTRIBUTION ARRAY<STRUCT>

Histogramme du nombre de participants à chaque tentative de commit.

Le tableau présente la structure suivante :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Pour en savoir plus sur les types de valeurs, consultez Distribution et Exponentiel.

Pour calculer les centiles des participants à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

PARTICIPANTS_DISTRIBUTION_JSON_STRING STRING

Représentation sous forme de chaîne compatible JSON de la statistique PARTICIPANTS_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne PARTICIPANTS_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Pour calculer les centiles des participants à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

Exemples de requêtes

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

Répertorier les statistiques de base de chaque transaction sur une période donnée

La requête suivante renvoie les données brutes correspondant aux principales transactions exécutées au cours de la minute précédente.

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       operations_by_table,
       avg_bytes
FROM spanner_sys.txn_stats_top_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_minute);
Sortie de la requête
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds avg_commit_latency_seconds operations_by_table avg_bytes
40015598317 [] ["Routes.name", "Cars.model"] ["Users"] 0.006578737 0.006547737 [["Cars",1107,30996],["Routes",560,26880]] 25286
20524969030 ["id", "no"] [] [] 0.001732442 0.000247442 [] 0
77848338483 [] [] ["Cars", "Routes"] 0.033467418 0.000251418 [] 0

Répertorier les transactions avec la latence de commit moyenne la plus élevée

La requête suivante renvoie les transactions présentant une latence de commit moyenne élevée au cours de l'heure précédente, classées de la latence de commit moyenne la plus élevée à la plus faible.

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_hour)
ORDER BY avg_commit_latency_seconds DESC;
Sortie de la requête
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds avg_commit_latency_seconds avg_bytes
40015598317 [] ["Routes.name", "Cars.model"] ["Users"] 0.006578737 0.006547737 25286
77848338483 [] [] ["Cars", "Routes"] 0.033467418 0.000251418 0
20524969030 ["id", "no"] [] [] 0.001732442 0.000247442 0

Rechercher la latence moyenne des transactions qui lisent certaines colonnes

La requête suivante renvoie les informations de latence moyenne pour les transactions qui lisent la colonne ADDRESS à partir des statistiques de l'heure précédente :

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds
FROM spanner_sys.txn_stats_top_hour
WHERE 'ADDRESS' IN UNNEST(read_columns)
ORDER BY avg_total_latency_seconds DESC;
Sortie de la requête
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds
77848338483 ["ID", "ADDRESS"] [] ["Cars", "Routes"] 0.033467418
40015598317 ["ID", "NAME", "ADDRESS"] [] ["Users"] 0.006578737

Lister les transactions en fonction du nombre moyen d'octets modifiés

La requête suivante renvoie les transactions échantillonnées au cours de la dernière heure, classées par nombre moyen d'octets modifiés par la transaction.

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
ORDER BY avg_bytes DESC;
Sortie de la requête
fprint read_columns write_constructive_columns write_delete_tables avg_bytes
40015598317 [] [] ["Users"] 25286
77848338483 [] [] ["Cars", "Routes"] 12005
20524969030 ["ID", "ADDRESS"] [] ["Users"] 10923

Statistiques globales

SPANNER_SYS contient également des tables permettant de stocker des données agrégées pour toutes les transactions pour lesquelles Spanner a capturé des statistiques au cours d'une période spécifique :

  • SPANNER_SYS.TXN_STATS_TOTAL_MINUTE : statistiques agrégées pour toutes les transactions par intervalles d'une minute
  • SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE : statistiques agrégées pour toutes les transactions par intervalles de 10 minutes
  • SPANNER_SYS.TXN_STATS_TOTAL_HOUR : statistiques agrégées pour toutes les transactions par intervalles d'une heure

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

  • Chaque table contient des données pour des intervalles de temps qui ne se chevauchent pas, dont la durée est 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 transaction 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 transactions exécutées sur la base de données au cours de l'intervalle spécifié. Il n'y a qu'une seule ligne par intervalle de temps.

  • Les statistiques capturées dans les tables SPANNER_SYS.TXN_STATS_TOTAL_* peuvent inclure des transactions que Spanner n'a pas capturées dans les tables SPANNER_SYS.TXN_STATS_TOP_*.

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

    • Nombre de tentatives de commit
    • Nombre de nouvelles tentatives de commit
    • Participants à la transaction
    • Latences des transactions
    • Octets écrits

    Pour en savoir plus, consultez 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 cette statistique a été capturée.
ATTEMPT_COUNT INT64 Nombre total de tentatives de transaction, y compris celles qui sont abandonnées avant l'appel de "commit". Ce nombre représente le nombre total de tentatives au cours de l'intervalle spécifié. Pour en savoir plus sur les intervalles, consultez Intervalles.
COMMIT_ATTEMPT_COUNT INT64 Nombre total de tentatives de commit de transaction. Ce nombre doit correspondre au nombre d'appels à la méthode commit de la transaction. Ce nombre représente le nombre total de tentatives de commit au cours de l'intervalle spécifié. Pour en savoir plus sur les intervalles, consultez Intervalles.
COMMIT_ABORT_COUNT INT64 Nombre total de tentatives de transaction qui sont abandonnées, y compris celles qui sont abandonnées avant d'appeler la méthode commit de la transaction. Ce nombre représente le nombre total d'abandons au cours de l'intervalle spécifié. Pour en savoir plus sur les intervalles, consultez Intervalles.
COMMIT_RETRY_COUNT INT64 Nombre de tentatives de commit qui sont des nouvelles tentatives d'essais précédemment abandonnés. Une transaction Spanner peut avoir été tentée plusieurs fois avant d'être validée en raison de conflits de verrouillage ou d'événements temporaires. Un nombre élevé de nouvelles tentatives par rapport aux tentatives de commit indique qu'il peut y avoir des problèmes à examiner. Pour en savoir plus, consultez la section Comprendre les transactions et le nombre de commits sur cette page.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Nombre total de tentatives de commit de transaction ayant renvoyé des erreurs de condition préalable non remplie, telles que des violations d'index UNIQUE, une ligne existant déjà ou une ligne introuvable.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT INT64 Nombre total de tentatives de transaction initiées avec le niveau d'isolation SERIALIZABLE et le verrouillage PESSIMISTIC. Il s'agit d'un sous-ensemble de ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT INT64 Nombre total de tentatives de transaction initiées avec le niveau d'isolation REPEATABLE READ et le verrouillage OPTIMISTIC. Il s'agit d'un sous-ensemble de ATTEMPT_COUNT.
AVG_PARTICIPANTS FLOAT64 Nombre moyen de participants à chaque tentative de commit. Pour en savoir plus sur les participants, consultez Cycle de vie des lectures et écritures Spanner.
AVG_TOTAL_LATENCY_SECONDS FLOAT64 Nombre moyen de secondes écoulées entre la première opération de la transaction et le commit ou l'abandon.
AVG_COMMIT_LATENCY_SECONDS FLOAT64 Nombre moyen de secondes nécessaires pour effectuer l'opération de commit.
AVG_BYTES FLOAT64 Nombre moyen d'octets écrits par la transaction.
TOTAL_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogramme de la latence totale de commit, qui correspond au délai entre l'heure de début de la première opération transactionnelle et l'heure de commit ou d'abandon pour toutes les tentatives de transaction.

Si une transaction est annulée plusieurs fois, puis validée, la latence est mesurée pour chaque tentative jusqu'à la validation finale. Les valeurs sont mesurées en secondes.

Le tableau contient un seul élément et est du type suivant :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Pour en savoir plus sur les valeurs, consultez Distribution et Exponentiel.

Pour calculer la latence du centile à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), qui renvoie le n-ième centile estimé. Pour obtenir un exemple, consultez Rechercher le 99e centile de latence pour les transactions.

Pour en savoir plus, consultez Centiles et métriques de distribution.

OPERATIONS_BY_TABLE ARRAY<STRUCT>

Impact des opérations INSERT ou UPDATE par toutes les transactions, par table. Cela est indiqué par le nombre de fois où les lignes sont affectées et le nombre d'octets écrits.

Cette colonne permet de visualiser la charge sur les tables et fournit des insights sur la vitesse à laquelle les transactions écrivent dans les tables.

Spécifiez le tableau comme suit :
ARRAY<STRUCT<
  TABLE STRING(MAX),
  INSERT_OR_UPDATE_COUNT INT64,
  INSERT_OR_UPDATE_BYTES INT64>>

TOTAL_LATENCY_DISTRIBUTION_JSON_STRING STRING

Histogramme de la latence totale de commit, qui correspond au délai entre l'heure de début de la première opération transactionnelle et l'heure de commit ou d'abandon, pour toutes les tentatives d'une transaction.

Représentation sous forme de chaîne compatible JSON de la statistique TOTAL_LATENCY_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que la STRUCT définie dans TOTAL_LATENCY_DISTRIBUTION.

Si une transaction est abandonnée plusieurs fois, puis validée, la latence est mesurée pour chaque tentative jusqu'à la validation finale. Les valeurs sont mesurées en secondes.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL. Cette colonne contient la distribution.

Pour calculer la latence du centile à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), qui renvoie le n-ième centile estimé. Pour obtenir un exemple associé, consultez Rechercher la latence au 99e centile pour les transactions à l'aide de la colonne TOTAL_LATENCY_DISTRIBUTION_JSON_STRING.

Pour en savoir plus, consultez Centiles et métriques de distribution.

OPERATIONS_BY_TABLE_JSON_STRING STRING

Impact des opérations INSERT ou UPDATE par la transaction sur une base par table. Cela est indiqué par le nombre de fois où les lignes sont affectées et le nombre d'octets écrits.

Représentation sous forme de chaîne compatible JSON de la colonne OPERATIONS_BY_TABLE. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne OPERATIONS_BY_TABLE.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Cette colonne permet de visualiser la charge sur les tables et fournit des insights sur la vitesse à laquelle une transaction écrit dans les tables.

COMMIT_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogramme du nombre de secondes nécessaires pour effectuer l'opération de commit.

Le tableau présente la structure suivante :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Pour en savoir plus sur les types de valeurs, consultez Distribution et Exponentiel.

Pour calculer les centiles de latence de commit à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

COMMIT_LATENCY_DISTRIBUTION_JSON_STRING STRING

Représentation sous forme de chaîne compatible JSON de la statistique COMMIT_LATENCY_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne COMMIT_LATENCY_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Pour calculer les centiles de latence de commit à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

PARTICIPANTS_DISTRIBUTION ARRAY<STRUCT>

Histogramme du nombre de participants à chaque tentative de commit.

Le tableau présente la structure suivante :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Pour en savoir plus sur les types de valeurs, consultez Distribution et Exponentiel.

Pour calculer les centiles des participants à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

PARTICIPANTS_DISTRIBUTION_JSON_STRING STRING

Représentation sous forme de chaîne compatible JSON de la statistique PARTICIPANTS_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne PARTICIPANTS_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Pour calculer les centiles des participants à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

Exemples de requêtes

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

Trouver le nombre total de tentatives de commit pour toutes les transactions

La requête suivante renvoie le nombre total de tentatives de commit pour toutes les transactions au cours de la dernière minute complète :

SELECT interval_end,
       commit_attempt_count
FROM spanner_sys.txn_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_minute)
ORDER BY interval_end;
Sortie de la requête
interval_end commit_attempt_count
2020-01-17 11:46:00-08:00 21

Notez qu'il n'y a qu'une ligne dans le résultat, car les statistiques agrégées ne comportent qu'une seule entrée par interval_end pour une durée donnée.

Rechercher la latence de commit totale pour toutes les transactions

La requête suivante renvoie la latence de commit totale pour toutes les transactions au cours des 10 dernières minutes :

SELECT (avg_commit_latency_seconds * commit_attempt_count / 60 / 60)
  AS total_commit_latency_hours
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute);
Sortie de la requête
total_commit_latency_hours
0.8967

Notez qu'il n'y a qu'une ligne dans le résultat, car les statistiques agrégées ne comportent qu'une seule entrée par interval_end pour une durée donnée.

Rechercher la latence au 99e centile pour les transactions

Les requêtes suivantes renvoient le 99e centile du temps d'exécution des requêtes exécutées au cours des 10 dernières minutes.

Pour les bases de données de dialecte GoogleSQL, vous pouvez utiliser la colonne TOTAL_LATENCY_DISTRIBUTION :

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;

Pour les bases de données de dialecte PostgreSQL, utilisez plutôt la colonne TOTAL_LATENCY_JSON_DISTRIBUTION_JSON_STRING :

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution_json_string, 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;
Sortie de la requête
interval_end avg_total_latency_seconds percentile_latency
2022-08-17 11:46:00-08:00 0.34576998305986395 9.00296190476190476

Notez la différence importante entre la latence moyenne et la latence du 99e centile. La latence au 99e centile permet d'identifier les transactions aberrantes possibles avec une latence élevée.

Le résultat ne contient qu'une seule ligne, car les statistiques agrégées ne comportent qu'une seule entrée par interval_end pour une durée donnée.

Conservation des données

Au minimum, Spanner conserve les données de chaque table pendant les périodes suivantes :

  • SPANNER_SYS.TXN_STATS_TOP_MINUTE et SPANNER_SYS.TXN_STATS_TOTAL_MINUTE : intervalles couvrant les six heures précédentes.

  • SPANNER_SYS.TXN_STATS_TOP_10MINUTE et SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE : intervalles couvrant les quatre derniers jours.

  • SPANNER_SYS.TXN_STATS_TOP_HOUR et SPANNER_SYS.TXN_STATS_TOTAL_HOUR : intervalles couvrant les 30 jours précédents.

Les statistiques de transaction dans Spanner fournissent des informations sur la façon dont une application utilise la base de données et sont utiles pour examiner les problèmes de performances. Par exemple, vous pouvez vérifier s'il existe des transactions lentes susceptibles de provoquer des conflits, ou identifier les sources potentielles de charge élevée, telles que des volumes importants de mises à jour d'une colonne particulière.

Comprendre les transactions et le nombre de commits

Une transaction Spanner peut devoir être tentée plusieurs fois avant d'être validée. Cela se produit le plus souvent lorsque deux transactions tentent de travailler sur les mêmes données en même temps, et que l'une des transactions doit être abandonnée pour préserver la propriété d'isolation de la transaction. Voici d'autres événements temporaires pouvant également entraîner l'abandon d'une transaction :

  • Problèmes de réseau temporaires.

  • Modifications du schéma de base de données appliquées pendant la validation d'une transaction.

  • L'instance Spanner n'a pas la capacité de traiter toutes les requêtes qu'elle reçoit.

Dans ce cas, un client doit relancer la transaction abandonnée jusqu'à ce qu'elle soit validée ou qu'elle expire. Pour les utilisateurs des bibliothèques clientes Spanner officielles, chaque bibliothèque a mis en œuvre un mécanisme de nouvelle tentative automatique. Si vous utilisez une version personnalisée du code client, encapsulez vos commits de transaction dans une boucle de nouvelle tentative.

Une transaction Spanner peut également être abandonnée en raison d'une erreur non renouvelable, telle qu'un délai avant expiration de la transaction, des problèmes d'autorisation ou un nom de table ou de colonne non valide. Il n'est pas nécessaire de relancer ces transactions, et la bibliothèque cliente Spanner renvoie immédiatement l'erreur.

Le tableau suivant décrit quelques exemples de la façon dont COMMIT_ATTEMPT_COUNT, COMMIT_ABORT_COUNT et COMMIT_RETRY_COUNT sont consignés dans différents scénarios.

Scénario COMMIT_ATTEMPT_COUNT COMMIT_ABORT_COUNT COMMIT_RETRY_COUNT
La transaction a bien été validée dès la première tentative. 1 0 0
La transaction a été annulée en raison d'une erreur de délai d'expiration. 1 1 0
La transaction a été annulée en raison d'un problème réseau temporaire et a bien été validée après une nouvelle tentative. 2 1 1
Cinq transactions avec la même empreinte sont exécutées dans un intervalle de 10 minutes. Trois des transactions ont été validées lors de la première tentative, tandis que deux transactions ont été abandonnées, puis validées lors de la première nouvelle tentative. 7 2 2

Les données des tables transaction-stats sont des données agrégées pour un intervalle de temps. Pour un intervalle particulier, il est possible qu'une transaction soit abandonnée et qu'une nouvelle tentative se produise autour des limites et se retrouve dans différents buckets. Par conséquent, dans un intervalle de temps donné, les abandons et les nouvelles tentatives peuvent ne pas être égaux.

Ces statistiques sont conçues pour le dépannage et l'introspection, et leur exactitude n'est pas garantie à 100 %. Les statistiques sont agrégées en mémoire avant d'être stockées dans des tables Spanner. Lors d'une mise à niveau ou d'autres activités de maintenance, les serveurs Spanner peuvent redémarrer, ce qui affecte la précision des chiffres.

Résoudre les conflits de base de données à l'aide des statistiques de transaction

Vous pouvez utiliser du code SQL ou le tableau de bord Insights sur les transactions pour afficher les transactions de votre base de données susceptibles de provoquer des latences élevées en raison de conflits de verrouillage.

Les rubriques suivantes expliquent comment examiner ces transactions à l'aide du code SQL.

Sélectionnez une période à examiner

Vous pouvez le trouver dans l'application qui utilise Spanner.

Pour les besoins de cet exercice, supposons que le problème a commencé à se produire vers 17h20 le 17 mai 2020.

Vous pouvez utiliser des tags de transaction pour identifier la source de la transaction et établir une corrélation entre la table des statistiques de transaction et les tables de statistiques de verrouillage afin de résoudre efficacement les problèmes de conflit de verrouillage. Pour en savoir plus, consultez Résoudre les problèmes à l'aide de tags de transaction.

Recueillir les statistiques de transaction pour la période sélectionnée

Pour commencer l'investigation, interrogez la table TXN_STATS_TOTAL_10MINUTE au moment où le problème a commencé. Les résultats de cette requête montrent l'évolution de la latence et d'autres statistiques de transaction au cours de cette période.

Par exemple, la requête suivante renvoie les statistiques de transaction agrégées de 4:30 pm à 7:40 pm (inclus).

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  commit_attempt_count,
  commit_abort_count
FROM SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
ORDER BY interval_end;

Le tableau suivant présente des exemples de données renvoyées par la requête.

interval_end avg_total_latency_seconds commit_attempt_count commit_abort_count
2020-05-17 16:40:00-07:00 0,0284 315691 5170
2020-05-17 16:50:00-07:00 0,0250 302124 3828
2020-05-17 17:00:00-07:00 0,0460 346087 11382
2020-05-17 17:10:00-07:00 0,0864 379964 33826
2020-05-17 17:20:00-07:00 0,1291 390343 52549
2020-05-17 17:30:00-07:00 0,1314 456455 76392
2020-05-17 17:40:00-07:00 0,1598 507774 121458
2020-05-17 17:50:00-07:00 0,1641 516587 115875
2020-05-17 18:00:00-07:00 0,1578 552711 122626
2020-05-17 18:10:00-07:00 0,1750 569460 154205
2020-05-17 18:20:00-07:00 0,1727 613571 160772
2020-05-17 18:30:00-07:00 0,1588 601994 143044
2020-05-17 18:40:00-07:00 0,2025 604211 170019
2020-05-17 18:50:00-07:00 0,1615 601622 135601
2020-05-17 19:00:00-07:00 0,1653 596804 129511
2020-05-17 19:10:00-07:00 0,1414 560023 112247
2020-05-17 19:20:00-07:00 0,1367 570864 100596
2020-05-17 19:30:00-07:00 0,0894 539729 65316
2020-05-17 19:40:00-07:00 0,0820 479151 40398

La latence agrégée et le nombre d'abandons sont plus élevés pendant les périodes mises en surbrillance. Choisissez un intervalle de 10 minutes où la latence agrégée et le nombre d'abandons, ou les deux, sont élevés. L'intervalle se terminant à 2020-05-17T18:40:00 est utilisé à l'étape suivante pour identifier les transactions qui contribuent à une latence élevée et à un nombre d'abandons élevé.

Identifier les transactions qui subissent une latence élevée

Interrogez la table TXN_STATS_TOP_10MINUTE pour l'intervalle choisi à l'étape précédente. À l'aide de ces données, vous pouvez commencer à identifier les transactions qui connaissent une latence élevée, un nombre élevé d'abandons, ou les deux.

Exécutez la requête suivante pour obtenir les transactions ayant le plus d'impact sur les performances, par ordre décroissant de latence totale, pour l'exemple d'intervalle se terminant à 2020-05-17T18:40:00.

SELECT
  interval_end,
  fprint,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  ROUND(avg_commit_latency_seconds,4) as avg_commit_latency_seconds,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC;
interval_end fprint avg_total_latency_seconds avg_commit_latency_seconds commit_attempt_count commit_abort_count commit_retry_count
2020-05-17 18:40:00-07:00 15185072816865185658 0,3508 0,0139 278802 142205 129884
2020-05-17 18:40:00-07:00 15435530087434255496 0,1633 0,0142 129012 27177 24559
2020-05-17 18:40:00-07:00 14175643543447671202 0,1423 0,0133 5357 636 433
2020-05-17 18:40:00-07:00 898069986622520747 0,0198 0,0158 6 0 0
2020-05-17 18:40:00-07:00 10510121182038036893 0,0168 0,0125 7 0 0
2020-05-17 18:40:00-07:00 9287748709638024175 0,0159 0,0118 4269 1 0
2020-05-17 18:40:00-07:00 7129109266372596045 0,0142 0,0102 182227 0 0
2020-05-17 18:40:00-07:00 15630228555662391800 0,0120 0,0107 58 0 0
2020-05-17 18:40:00-07:00 7907238229716746451 0,0108 0,0097 65 0 0
2020-05-17 18:40:00-07:00 10158167220149989178 0,0095 0,0047 3454 0 0
2020-05-17 18:40:00-07:00 9353100217060788102 0,0093 0,0045 725 0 0
2020-05-17 18:40:00-07:00 9521689070912159706 0,0093 0,0045 164 0 0
2020-05-17 18:40:00-07:00 11079878968512225881 0,0064 0,0019 65 0 0

La première ligne (mise en surbrillance) du tableau précédent montre une transaction présentant une latence élevée en raison d'un nombre élevé d'abandons de commit. Le nombre de nouvelles tentatives de commit est également élevé, ce qui indique que les commits abandonnés ont été relancés par la suite. L'étape suivante consiste à examiner plus en détail la cause de ce problème.

Identifier les colonnes impliquées dans une transaction présentant une latence élevée

Dans cette étape, vérifiez si les transactions à latence élevée s'exécutent sur le même ensemble de colonnes en récupérant les données read_columns, write_constructive_columns et write_delete_tables pour les transactions présentant un nombre élevé d'abandons. La valeur FPRINT sera également utile à l'étape suivante.

SELECT
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC LIMIT 3;
fprint read_columns write_constructive_columns write_delete_tables
15185072816865185658 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares] [TestHigherLatency._exists,TestHigherLatency.shares,TestHigherLatency_lang_status_score_index.shares] []
15435530087434255496 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score] [TestHigherLatency._exists,TestHigherLatency.likes,TestHigherLatency_lang_status_score_index.likes] []
14175643543447671202 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount] [TestHigherLatency._exists,TestHigherLatency.ugcCount,TestHigherLatency_lang_status_score_index.ugcCount] []

Comme le résultat le montre dans le tableau précédent, les transactions présentant la latence totale moyenne la plus élevée lisent les mêmes colonnes. Il existe également un conflit d'écriture, car les transactions écrivent dans la même colonne, à savoir TestHigherLatency._exists.

Déterminer l'évolution des performances des transactions au fil du temps

Vous pouvez voir comment les statistiques associées à cette forme de transaction ont évolué au fil du temps. Utilisez la requête suivante, où $FPRINT correspond à l'empreinte de la transaction à latence élevée déterminée à l'étape précédente.

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds, 3) AS latency,
  ROUND(avg_commit_latency_seconds, 3) AS commit_latency,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count,
  commit_failed_precondition_count,
  avg_bytes
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
  AND fprint = $FPRINT
ORDER BY interval_end;
interval_end latence commit_latency commit_attempt_count commit_abort_count commit_retry_count commit_failed_precondition_count avg_bytes
2020-05-17 16:40:00-07:00 0,095 0,010 53230 4752 4330 0 91
2020-05-17 16:50:00-07:00 0,069 0,009 61264 3589 3364 0 91
2020-05-17 17:00:00-07:00 0,150 0,010 75868 10557 9322 0 91
2020-05-17 17:10:00-07:00 0,248 0,013 103151 30220 28483 0 91
2020-05-17 17:20:00-07:00 0,310 0,012 130078 45655 41966 0 91
2020-05-17 17:30:00-07:00 0,294 0,012 160064 64930 59933 0 91
2020-05-17 17:40:00-07:00 0,315 0,013 209614 104949 96770 0 91
2020-05-17 17:50:00-07:00 0,322 0,012 215682 100408 95867 0 90
2020-05-17 18:00:00-07:00 0,310 0,012 230932 106728 99462 0 91
2020-05-17 18:10:00-07:00 0,309 0,012 259645 131049 125889 0 91
2020-05-17 18:20:00-07:00 0,315 0,013 272171 137910 129411 0 90
2020-05-17 18:30:00-07:00 0,292 0,013 258944 121475 115844 0 91
2020-05-17 18:40:00-07:00 0,350 0,013 278802 142205 134229 0 91
2020-05-17 18:50:00-07:00 0,302 0,013 256259 115626 109756 0 91
2020-05-17 19:00:00-07:00 0,315 0.014 250560 110662 100322 0 91
2020-05-17 19:10:00-07:00 0,271 0.014 238384 99025 90187 0 91
2020-05-17 19:20:00-07:00 0,273 0.014 219687 84019 79874 0 91
2020-05-17 19:30:00-07:00 0.198 0,013 195357 59370 55909 0 91
2020-05-17 19:40:00-07:00 0,181 0,013 167514 35705 32885 0 91

Dans ce résultat, observez que la latence totale est élevée pour la période mise en évidence. De plus, si la latence totale est élevée, commit_attempt_count, commit_abort_count et commit_retry_count sont également élevés même si la latence de commit (commit_latency) n'a guère changé. Étant donné que les commits de transactions sont annulés plus fréquemment, le nombre de tentatives de commit est également élevé en raison des nouvelles tentatives de commit.

Conclusion

Dans cet exemple, le nombre élevé d'abandons de commit était à l'origine de la latence élevée. L'étape suivante consiste à examiner les messages d'erreur associés aux abandons de commit et reçus par l'application afin de connaître la raison de ces abandons. En inspectant les journaux de l'application, vous pouvez voir que l'application a effectivement modifié sa charge de travail pendant cette période, c'est-à-dire qu'une autre forme de transaction est apparue avec un attempts_per_second élevé, et que cette autre transaction (peut-être une tâche de nettoyage nocturne) était responsable des conflits de verrouillage supplémentaires.

Identifier les transactions qui n'ont pas été relancées correctement

La requête suivante renvoie les transactions échantillonnées au cours des dix dernières minutes qui ont un nombre élevé d'abandons de commit, mais sans nouvelle tentative.

SELECT
  *
FROM (
  SELECT
    fprint,
    SUM(commit_attempt_count) AS total_commit_attempt_count,
    SUM(commit_abort_count) AS total_commit_abort_count,
    SUM(commit_retry_count) AS total_commit_retry_count
  FROM
    SPANNER_SYS.TXN_STATS_TOP_10MINUTE
  GROUP BY
    fprint )
WHERE
  total_commit_retry_count = 0
  AND total_commit_abort_count > 0
ORDER BY
  total_commit_abort_count DESC;
fprint total_commit_attempt_count total_commit_abort_count total_commit_retry_count
1557557373282541312 3367894 44232 0
5776062322886969344 13566 14 0

La transaction avec l'empreinte 1557557373282541312 a été abandonnée 44 232 fois, mais n'a jamais été relancée. Cela semble suspect, car le nombre d'abandons est élevé et il est peu probable que chaque abandon ait été causé par une erreur ne pouvant pas être relancée. En revanche, la transaction avec l'empreinte 5776062322886969344 est moins suspecte, car le nombre total d'abandons n'est pas si élevé.

La requête suivante renvoie plus de détails sur la transaction avec l'empreinte 1557557373282541312,y compris read_columns, write_constructive_columns et write_delete_tables. Ces informations permettent d'identifier la transaction dans le code client, où la logique de nouvelle tentative peut être examinée pour ce scénario.

SELECT
  interval_end,
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM
  SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  fprint = 1557557373282541312
ORDER BY
  interval_end DESC;
interval_end fprint read_columns write_constructive_columns write_delete_tables commit_attempt_count commit_abort_count commit_retry_count
2021-01-27T18:30:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 805228 1839 0
2021-01-27T18:20:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 1034429 38779 0
2021-01-27T18:10:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 833677 2266 0
2021-01-27T18:00:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 694560 1348 0

La transaction implique une lecture de la colonne masquée Singers._exists pour vérifier l'existence d'une ligne. La transaction écrit également dans les colonnes Singers.FirstName et Singer.LastName. Ces informations peuvent vous aider à déterminer si le mécanisme de nouvelle tentative de transaction implémenté dans votre bibliothèque cliente personnalisée fonctionne comme prévu.

Étape suivante