Statistiques de transaction

Cloud Spanner fournit des tables intégrées qui stockent des statistiques sur les transactions. Vous pouvez récupérer des statistiques à partir 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 si des transactions de longue durée sont susceptibles d'affecter les performances ou les requêtes par seconde (RPS) de votre base de données. Autre scénario : lorsque vos applications clientes rencontrent une latence élevée pour l'exécution des transactions. L'analyse des statistiques de transaction peut aider à détecter des goulots d'étranglement, tels que de gros volumes de mises à jour d'une colonne particulière, ce qui peut affecter la latence.

Disponibilité

Les données SPANNER_SYS ne sont disponibles que via des interfaces SQL (par exemple, executeQuery et gcloud spanner databases execute-sql). Les autres méthodes de lecture unique fournies par Cloud Spanner ne sont pas compatibles avec SPANNER_SYS.

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 des transactions cumulées sur une minute.

  • SPANNER_SYS.TXN_STATS_TOP_10MINUTE : statistiques des transactions cumulées sur des intervalles de 10 minutes.

  • SPANNER_SYS.TXN_STATS_TOP_HOUR : statistiques des transactions cumulées sur 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.

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

    • 1 minute : 11:58:01 – 11:59:00
    • 10 minutes : 11:40:01 – 11:50:00
    • 1 heure : 10:00:01 – 11:00:00
  • Cloud Spanner regroupe les statistiques en fonction du FPRINT (empreinte) des transactions. FPRINT correspond au hachage calculé en fonction des opérations associées à la transaction.

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

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

Si Cloud Spanner ne parvient pas à stocker dans ces tables les statistiques de toutes les transactions exécutées pendant l'intervalle, le système donne la priorité aux transactions qui ont présenté le niveau de latence, de tentatives de commit et d'octets le plus élevé durant l'intervalle spécifié.

Schéma des tables

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.
FPRINT INT64 L'empreinte numérique est le hachage calculé en fonction des opérations impliquées dans la transaction. INTERVAL_END et FPRINT agissent ensemble comme 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 construite (c'est-à-dire attribuées à de nouvelles valeurs) par la transaction.
WRITE_DELETE_TABLES ARRAY<STRING> Ensemble de tables dans lesquelles des lignes ont été supprimées ou remplacées par la transaction.
COMMIT_ATTEMPT_COUNT INT64 Nombre total de tentatives de commit sur la transaction.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Nombre total d'échecs de condition préalable (FAILED_PRECONDITION) pour la transaction.
COMMIT_ABORT_COUNT INT64 Nombre de fois où les commits ont été annulés pour la transaction.
AVG_PARTICIPANTS FLOAT64 Nombre moyen de participants à chaque tentative de commit. Pour en savoir plus sur les participants, consultez la page Déroulement des opérations de lecture et d'écriture Cloud 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.

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 l'outil de ligne de commande gcloud ou de Cloud Console.

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,
       avg_bytes
FROM spanner_sys.txn_stats_top_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_minute);
Résultat 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"] ["Users"] 0.006578737 0.006547737 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 avec une latence de commit moyenne élevée au cours de l'heure précédente, trié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;
Résultat 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"] ["Users"] 0.006578737 0.006547737 25286
77848338483 [] [] ["Cars", "Routes"] 0.033467418 0.000251418 0
20524969030 ["id", "no"] [] [] 0.001732442 0.000247442 0

Trouver 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;
Résultat 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

Répertorier 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, triées en fonction du 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;
Résultat 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 de stockage des données agrégées pour toutes les transactions pour lesquelles Cloud Spanner a capturé des statistiques sur une période donnée :

  • SPANNER_SYS.TXN_STATS_TOTAL_MINUTE : statistiques globales pour toutes les transactions effectuées toutes les minutes
  • SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE : statistiques globales pour toutes les transactions effectuées durant des intervalles de 10 minutes
  • SPANNER_SYS.TXN_STATS_TOTAL_HOUR : statistiques globales pour toutes les transactions effectuées toutes les heures

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 transaction globales sont les suivants :

    • 1 minute : 11:58:01 – 11:59:00
    • 10 minutes : 11:40:01 – 11:50:00
    • 1 heure : 10:00:01 – 11:00:00
  • 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 par conséquent 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 Cloud Spanner n'a pas capturées dans les tables SPANNER_SYS.TXN_STATS_TOP_*.

Schéma des tables

Nom de la colonne Type Description
INTERVAL_END TIMESTAMP Fin de l'intervalle de temps au cours duquel cette statistique a été capturée.
COMMIT_ATTEMPT_COUNT INT64 Nombre total de tentatives de commit sur la transaction.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Nombre total d'échecs de condition préalable (FAILED_PRECONDITION) pour la transaction.
COMMIT_ABORT_COUNT INT64 Nombre de fois que les commits ont été annulés pour la transaction.
AVG_PARTICIPANTS FLOAT64 Nombre moyen de participants à chaque tentative de commit. Pour en savoir plus sur les participants, consultez la page Déroulement des opérations de lecture et d'écriture Cloud 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.

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 l'outil de ligne de commande gcloud ou de Cloud Console.

Trouver le nombre total de tentatives de commit pour une transaction au cours d'une période donnée

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;
Résultat 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 seule ligne dans le résultat, car les statistiques cumulées ne comportent qu'une entrée par interval_end pour une durée donnée.

Trouver la latence totale des commits sur 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);
Résultat de la requête
total_commit_latency_hours
0.8967

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

Conservation des données

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

  • 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 derniers jours.

Les statistiques de transaction dans Cloud Spanner fournissent des informations sur la façon dont une application utilise la base de données et sont utiles pour étudier les problèmes de performances. Par exemple, vous pouvez vérifier si des transactions plus lentes sont susceptibles de causer des conflits, ou identifier des sources potentielles de charge élevée, telles que des volumes de mises à jour importants sur une colonne donnée. À l'aide des étapes suivantes, nous vous montrerons comment utiliser les statistiques de transaction pour examiner les conflits dans votre base de données.

Résoudre les problèmes liés aux bases de données à l'aide des statistiques de transaction

Étape 1: Sélectionner une période à examiner

La période peut-être trouvée à partir de l'application qui utilise Cloud Spanner.

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

Étape 2: Collecter les statistiques de transaction pour la période sélectionnée

Pour commencer notre enquête, nous allons interroger la table TXN_STATS_TOTAL_10MINUTE aux environs de l'heure du début du problème. Les résultats de cette requête nous montrent comment la latence et les autres statistiques de transaction ont changé au cours de cette période.

Par exemple, la requête suivante renvoie les statistiques de transaction cumulé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 répertorie des exemples de données renvoyés par notre 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

Ici, nous constatons que la latence agrégée et l'abandon sont plus élevées dans les périodes mises en évidence. Nous pouvons choisir n'importe quel intervalle de 10 minutes où la latence cumulée et/ou le nombre d'abandons sont élevés. Choisissons l'intervalle se terminant à 2020-05-17T18:40:00 et utilisons-le dans l'étape suivante pour identifier les transactions qui contribuent à la latence élevée et à l'abandon.

Étape 3: Identifiez les transactions qui connaissent une latence élevée

Interrogeons à présent la table TXN_STATS_TOP_10MINUTE sur l'intervalle sélectionné à l'étape précédente. Ces données nous permettent d'identifier les transactions qui enregistrent une latence élevée et/ou un nombre d'abandons élevé.

Exécutez la requête suivante pour obtenir les principales transactions ayant un impact sur les performances, par ordre décroissant de latence totale pour notre 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
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
2020-05-17 18:40:00-07:00 15185072816865185658 0,3508 0,0139 278802 142205
2020-05-17 18:40:00-07:00 15435530087434255496 0,1633 0,0142 129012 27177
2020-05-17 18:40:00-07:00 14175643543447671202 0,1423 0,0133 5357 636
2020-05-17 18:40:00-07:00 898069986622520747 0,0198 0,0158 6 0
2020-05-17 18:40:00-07:00 10510121182038036893 0,0168 0,0125 7 0
2020-05-17 18:40:00-07:00 9287748709638024175 0,0159 0,0118 4269 1
2020-05-17 18:40:00-07:00 7129109266372596045 0,0142 0,0102 182227 0
2020-05-17 18:40:00-07:00 15630228555662391800 0,0120 0,0107 58 0
2020-05-17 18:40:00-07:00 7907238229716746451 0,0108 0,0097 65 0
2020-05-17 18:40:00-07:00 10158167220149989178 0,0095 0,0047 3454 0
2020-05-17 18:40:00-07:00 9353100217060788102 0,0093 0,0045 725 0
2020-05-17 18:40:00-07:00 9521689070912159706 0,0093 0,0045 164 0
2020-05-17 18:40:00-07:00 11079878968512225881 0,0064 0,0019 65 0

Nous voyons clairement que la première ligne (en surbrillance) du tableau précédent montre une transaction qui connaît une latence élevée en raison d'un nombre élevé d'abandons de commit. À l'étape suivante, nous examinerons le problème afin d'identifier la cause du problème.

Étape 4: Identifier les colonnes impliquées dans une transaction présentant une latence élevée

Lors de cette étape, nous allons vérifier si les transactions à latence élevée fonctionnent 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 avec un nombre d'abandons élevé. 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
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. Nous pouvons également observer un conflit d'écriture, car les transactions écrivent dans la même colonne, à savoir TestHigherLatency._exists.

Étape 5: Déterminer l'évolution des performances des transactions au fil du temps

Nous pouvons voir l'évolution des statistiques associées à cette forme de transaction sur une période donnée. Utilisez la requête suivante, où $FPRINT est l'empreinte de la transaction à latence élevée de 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_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_failed_precondition_count avg_bytes
2020-05-17 16:40:00-07:00 0,095 0,010 53230 4752 0 91
2020-05-17 16:50:00-07:00 0,069 0,009 61264 3589 0 91
2020-05-17 17:00:00-07:00 0,150 0,010 75868 10557 0 91
2020-05-17 17:10:00-07:00 0,248 0,013 103151 30220 0 91
2020-05-17 17:20:00-07:00 0,310 0,012 130078 45655 0 91
2020-05-17 17:30:00-07:00 0,294 0,012 160064 64930 0 91
2020-05-17 17:40:00-07:00 0,315 0,013 209614 104949 0 91
2020-05-17 17:50:00-07:00 0,322 0,012 215682 100408 0 90
2020-05-17 18:00:00-07:00 0,310 0,012 230932 106728 0 91
2020-05-17 18:10:00-07:00 0,309 0,012 259645 131049 0 91
2020-05-17 18:20:00-07:00 0,315 0,013 272171 137910 0 90
2020-05-17 18:30:00-07:00 0,292 0,013 258944 121475 0 91
2020-05-17 18:40:00-07:00 0,350 0,013 278802 142205 0 91
2020-05-17 18:50:00-07:00 0,302 0,013 256259 115626 0 91
2020-05-17 19:00:00-07:00 0,315 0,014 250560 110662 0 91
2020-05-17 19:10:00-07:00 0,271 0,014 238384 99025 0 91
2020-05-17 19:20:00-07:00 0,273 0,014 219687 84019 0 91
2020-05-17 19:30:00-07:00 0.198 0,013 195357 59370 0 91
2020-05-17 19:40:00-07:00 0,181 0,013 167514 35705 0 91

Dans la sortie ci-dessus, nous pouvons observer que la latence totale est élevée pour la période en surbrillance. Et là où la latence totale est élevée, commit_attempt_count et commit_abort_coun le sont également, même si la latence de commit (commit_latency) n'a pas beaucoup changé. Étant donné que les commits de transaction sont annulés plus souvent, les tentatives de commit sont également élevées en raison des nouvelles tentatives de commit.

Étape 6 : Conclusion

Dans cet exemple, nous avons constaté que l'abandon d'un commit était la cause d'une latence élevée. L'étape suivante consiste à examiner les messages d'erreur d'abandon de commit reçus par l'application pour connaître la raison de l'abandon. En inspectant les journaux dans l'application, nous constatons que celle-ci a réellement modifié sa charge de travail pendant cette période, c'est-à-dire qu'une autre forme de transaction s'est affichée avec un nombre élevé de attempts_per_second, et que cette transaction différente (peut-être une tâche de nettoyage nocturne) était responsable des conflits de verrouillage supplémentaires.

Étape suivante