Statistiche sulle transazioni

Spanner fornisce tabelle integrate che archiviano le statistiche sulle transazioni. Tu può recuperare statistiche da queste tabelle SPANNER_SYS.TXN_STATS* utilizzando SQL istruzioni.

Quando utilizzare le statistiche sulle transazioni

Le statistiche sulle transazioni sono utili per analizzare i problemi di rendimento. Ad esempio: puoi controllare se ci sono transazioni con esecuzione lenta che potrebbero che influisce sulle prestazioni o sul valore di query al secondo (QPS) del tuo database. Un altro si verifica quando le applicazioni client riscontrano un'elevata transazione latenza di esecuzione. L'analisi delle statistiche sulle transazioni può aiutare a scoprire potenziali colli di bottiglia, quali volumi elevati di aggiornamenti di una determinata colonna, il che potrebbe influire sulla latenza.

Disponibilità

I dati di SPANNER_SYS sono disponibili solo tramite le interfacce SQL. Ad esempio:

  • Pagina Spanner Studio di un database nella console Google Cloud

  • Il comando gcloud spanner databases execute-sql

  • Dashboard Informazioni sulle transazioni

  • API executeQuery

Gli altri metodi di lettura singoli forniti da Spanner non supportano SPANNER_SYS.

Statistiche sulla latenza raggruppate per transazione

Le tabelle seguenti monitorano le statistiche per il consumo di risorse TOP transazioni effettuate durante un determinato periodo di tempo.

  • SPANNER_SYS.TXN_STATS_TOP_MINUTE: statistiche sulle transazioni aggregate in 1 a intervalli di minuti.

  • SPANNER_SYS.TXN_STATS_TOP_10MINUTE: statistiche sulle transazioni aggregate su Intervalli di 10 minuti.

  • SPANNER_SYS.TXN_STATS_TOP_HOUR: statistiche sulle transazioni aggregate in 1 intervalli di ore.

Queste tabelle hanno le seguenti proprietà:

  • Ogni tabella contiene dati per intervalli di tempo non sovrapposti della durata del nome di una tabella specifica.

  • Gli intervalli si basano sugli orari dell'orologio. 1 minuto gli intervalli terminano ogni minuto, gli intervalli di 10 minuti terminano ogni 10 minuti a partire all'ora e gli intervalli di 1 ora terminano ogni ora.

    Ad esempio, alle 11:59:30, gli intervalli più recenti disponibili per SQL le query sono:

    • 1 minuto: 11:58:00-11:58:59
    • 10 minuti: 11:40:00-11:49:59
    • 1 ora: 10:00:00–10:59:59

  • Spanner raggruppa le statistiche in base a FPRINT (impronta) del transazioni. Se è presente un tag transazione, FPRINT è l'hash del tag. Altrimenti, si tratta dell'hash calcolati in base alle operazioni coinvolte nella transazione.

  • Poiché le statistiche sono raggruppate in base a FPRINT, se la stessa transazione viene eseguite più volte in un intervallo di tempo, per la transazione in queste tabelle.

  • Ogni riga contiene le statistiche per tutte le esecuzioni di una determinata transazione per cui Spanner acquisisce le statistiche durante l'intervallo specificato.

  • Se Spanner non è in grado di archiviare le statistiche per tutte le transazioni eseguite durante l'intervallo in queste tabelle, il sistema assegna la priorità alle transazioni con con la latenza più alta, i tentativi di commit e i byte scritti durante l'intervallo intervallo di tempo.

  • Tutte le colonne delle tabelle sono nulli.

Schema tabella

Nome colonna Tipo Descrizione
INTERVAL_END TIMESTAMP Fine dell'intervallo di tempo in cui vengono eseguite le esecuzioni delle transazioni incluse si è verificato un errore.
TRANSACTION_TAG STRING Il tag facoltativo della transazione per questa operazione di transazione. Per ulteriori informazioni informazioni sull'utilizzo dei tag, consulta Risoluzione dei problemi relativi ai tag di transazione. Statistiche relative a più transazioni con stessa stringa tag sono raggruppate in una singola riga con "TRANSACTION_TAG" corrispondente alla stringa di tag specificata.
FPRINT INT64 L'hash del TRANSACTION_TAG, se presente; In caso contrario, viene calcolato in base alle operazioni coinvolte nella transazione. INTERVAL_END e FPRINT agiscono insieme come una chiave univoca per queste tabelle.
READ_COLUMNS ARRAY<STRING> L'insieme di colonne lette dalla transazione.
WRITE_CONSTRUCTIVE_COLUMNS ARRAY<STRING> L'insieme di colonne scritte in modo costruttivo (ovvero assegnate nuovi valori) dalla transazione.

Per le modifiche in tempo reale, se la transazione prevede la scrittura nelle colonne e tabelle controllate da un flusso di modifiche, WRITE_CONSTRUCTIVE_COLUMNS conterrà due colonne: .data e ._exists 1, preceduto dal nome di un flusso di modifiche.
WRITE_DELETE_TABLES ARRAY<STRING> L'insieme di tabelle le cui righe sono state eliminate o sostituite dalla transazione.
ATTEMPT_COUNT INT64 Numero totale di tentativi di transazione, inclusi i tentativi tentativi che si interrompono prima di chiamare "commit".
COMMIT_ATTEMPT_COUNT INT64 Numero totale di tentativi di commit della transazione. Deve corrispondere al numero delle chiamate al metodo commit della transazione.
COMMIT_ABORT_COUNT INT64 Numero totale di tentativi di transazione interrotti, inclusi quelli che sono state interrotte prima di chiamare il commit della transazione .
COMMIT_RETRY_COUNT INT64 Numero totale di nuovi tentativi da interrompere in precedenza tentativi. Una transazione Spanner può essere tentata più volte prima del commit a causa di contese di blocco o eventi temporanei. Una di nuovi tentativi rispetto ai tentativi di commit indica che potrebbero esserci che meritano un'analisi. Per ulteriori informazioni, vedi Informazioni sulle transazioni e sul numero di commit in questa pagina.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Numero totale di tentativi di commit della transazione che hanno restituito precondizione non riuscita errori, ad esempio UNIQUE violazioni dell'indice, riga già esistente, riga non trovata, e così via.
AVG_PARTICIPANTS FLOAT64 Numero medio di partecipanti a ogni tentativo di commit. Per scoprire di più sui partecipanti, vedi Vita di Spanner operazioni di lettura e Operazioni di scrittura.
AVG_TOTAL_LATENCY_SECONDS FLOAT64 Media di secondi intercorso tra la prima operazione della transazione e eseguire il commit/interruzione.
AVG_COMMIT_LATENCY_SECONDS FLOAT64 Media di secondi impiegati per eseguire l'operazione di commit.
AVG_BYTES FLOAT64 Numero medio di byte scritti dalla transazione.
TOTAL_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Un istogramma della latenza di commit totale, ovvero il tempo intercorso tra l'ora di inizio della prima operazione transazionale di interruzione per tutti i tentativi di una transazione.

Se una transazione viene interrotta più volte e poi il committente riesce, la latenza viene misurata per fino all'ultimo commit. I valori vengono misurati in secondi.

L'array contiene un solo elemento e presenta il seguente tipo:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Per ulteriori informazioni sui valori, consulta Distribuzione.

Per calcolare la latenza percentile desiderata dalla distribuzione, usa la funzione SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), che restituisce l'ennesimo percentile stimato. Per un esempio correlato, consulta Trovare la latenza del 99° percentile per le transazioni.

Per saperne di più, consulta Percentile e metriche con valori di distribuzione.

OPERATIONS_BY_TABLE ARRAY<STRUCT>

Impatto delle operazioni di INSERT o UPDATE da parte del transazioni per tabella. Ciò è indicato dal numero di volte le righe interessate e il numero di byte scritti.

Questa colonna consente di visualizzare il carico sulle tabelle e fornisce insight il tasso di scrittura di una transazione nelle tabelle.

Specifica l'array come segue:
ARRAY<STRUCT<
  TABLE STRING(MAX),
  INSERT_OR_UPDATE_COUNT INT64,
  INSERT_OR_UPDATE_BYTES INT64>>

1 _exists è un campo interno utilizzato per verificare se una che una determinata riga esista o meno.

Esempi di query

Questa sezione include diverse istruzioni SQL di esempio che recuperano le transazioni statistiche. Puoi eseguire queste istruzioni SQL utilizzando librerie client, gcloud spanner, o il Console Google Cloud.

Elenca le statistiche di base per ogni transazione in un determinato periodo di tempo

La seguente query restituisce i dati non elaborati per le transazioni principali in minuto precedente.

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);
Output query
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

Elenca le transazioni con la più alta latenza media di commit

La seguente query restituisce le transazioni con latenza di commit media elevata l'ora precedente, ordinati dalla latenza di commit media più alta a quella più bassa.

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;
Output query
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

Trovare la latenza media delle transazioni che leggono determinate colonne

La seguente query restituisce le informazioni sulla latenza media per le transazioni che leggono la colonna ADDRESS dalle statistiche di un'ora:

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;
Output query
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

Elenca le transazioni in base al numero medio di byte modificati

La seguente query restituisce le transazioni campionate nell'ultima ora, ordinate per il numero medio di byte modificati dalla transazione.

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
ORDER BY avg_bytes DESC;
Output query
Fprint read_columns write_constructive_columns write_delete_tables avg_bytes
40015598317 [] [] ["Users"] 25286
77848338483 [] [] ["Cars", "Routes"] 12005
20524969030 ["ID", "ADDRESS"] [] ["Users"] 10923

Statistiche aggregate

SPANNER_SYS contiene anche tabelle per archiviare i dati aggregati di tutte le transazioni Spanner ha acquisito le statistiche in un periodo di tempo specifico:

  • SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: statistiche aggregate per tutte le transazioni durante intervalli di 1 minuto
  • SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: statistiche aggregate per tutte le transazioni durante intervalli di 10 minuti
  • SPANNER_SYS.TXN_STATS_TOTAL_HOUR: statistiche aggregate per tutte le transazioni a intervalli di 1 ora

Le tabelle delle statistiche aggregate hanno le seguenti proprietà:

  • Ogni tabella contiene dati per intervalli di tempo non sovrapposti della durata del nome di una tabella specifica.

  • Gli intervalli sono basati sugli orari dell'orologio. Gli intervalli di 1 minuto terminano ogni minuto, 10 gli intervalli di minuti terminano ogni 10 minuti a partire dall'ora e ogni ora che terminano dopo un'ora.

    Ad esempio, alle 11:59:30, gli intervalli più recenti disponibili per SQL le query sulle statistiche aggregate delle transazioni sono:

    • 1 minuto: 11:58:00-11:58:59
    • 10 minuti: 11:40:00-11:49:59
    • 1 ora: 10:00:00–10:59:59

  • Ogni riga contiene le statistiche per tutte le transazioni eseguite nel durante l'intervallo specificato, aggregati. Ce n'è solo uno riga per intervallo di tempo.

  • Le statistiche acquisite nelle tabelle SPANNER_SYS.TXN_STATS_TOTAL_* potrebbero includono le transazioni che Spanner non ha acquisito SPANNER_SYS.TXN_STATS_TOP_* tabelle.

  • Alcune colonne di queste tabelle sono esposte come metriche in Cloud Monitoring. Le metriche esposte sono:

    • Conteggio tentativi di commit
    • Numero di nuovi tentativi di commit
    • Partecipanti alla transazione
    • Latenze di transazione
    • Byte scritti

    Per ulteriori informazioni, consulta Metriche di Spanner.

Schema tabella

Nome colonna Tipo Descrizione
INTERVAL_END TIMESTAMP Fine dell'intervallo di tempo in cui questa statistica è stata acquisita.
ATTEMPT_COUNT INT64 Il numero totale di tentativi di transazione, incluso il numero di tentativi tentativi che si interrompono prima di chiamare "commit".
COMMIT_ATTEMPT_COUNT INT64 Numero totale di tentativi di commit della transazione. Deve corrispondere al numero delle chiamate al metodo commit della transazione.
COMMIT_ABORT_COUNT INT64 Numero totale di tentativi di transazione interrotti, inclusi quelli che vengono interrotti prima di chiamare il campo commit della transazione .
COMMIT_RETRY_COUNT INT64 Numero di nuovi tentativi di commit interrotti in precedenza tentativi. È possibile che una transazione Spanner sia stata tentata più volte prima del commit a causa di contese di blocco o eventi temporanei. Una di nuovi tentativi rispetto ai tentativi di commit indica che potrebbero esserci che meritano un'analisi. Per ulteriori informazioni, vedi Informazioni sulle transazioni e sul numero di commit in questa pagina.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Numero totale di tentativi di commit della transazione che hanno restituito precondizione non riuscita errori, ad esempio UNIQUE violazioni dell'indice, riga già esistente, riga non trovata, e così via.
AVG_PARTICIPANTS FLOAT64 Numero medio di partecipanti a ogni tentativo di commit. Per scoprire di più sui partecipanti, vedi Vita di Spanner operazioni di lettura e Operazioni di scrittura.
AVG_TOTAL_LATENCY_SECONDS FLOAT64 Media di secondi intercorso tra la prima operazione della transazione e eseguire il commit/interruzione.
AVG_COMMIT_LATENCY_SECONDS FLOAT64 Media di secondi impiegati per eseguire l'operazione di commit.
AVG_BYTES FLOAT64 Numero medio di byte scritti dalla transazione.
TOTAL_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Un istogramma della latenza di commit totale, ovvero il tempo intercorso tra ora di inizio della prima operazione transazionale all'ora di commit o di interruzione per tutti i tentativi di transazione.

Se una transazione viene interrotta per poi eseguire il committente correttamente, la latenza viene misurata per ogni tentativo fino al commit finale riuscito. I valori vengono misurati in secondi.

L'array contiene un solo elemento e presenta il seguente tipo:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Per ulteriori informazioni sui valori, consulta Distribuzione.

Per calcolare la latenza percentile desiderata dalla distribuzione, usa la funzione SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), che restituisce l'ennesimo percentile stimato. Per un esempio, vedi Trovare il 99° percentile per le transazioni.

Per saperne di più, consulta Percentile e metriche con valori di distribuzione.

OPERATIONS_BY_TABLE ARRAY<STRUCT>

Impatto delle operazioni di INSERT o UPDATE di tutti transazioni per tabella. Ciò è indicato dal numero le righe interessate e il numero di byte scritti.

Questa colonna consente di visualizzare il carico sulle tabelle e fornisce insight su la frequenza con cui le transazioni scrivono nelle tabelle.

Specifica l'array come segue:
ARRAY<STRUCT<
  TABLE STRING(MAX),
  INSERT_OR_UPDATE_COUNT INT64,
  INSERT_OR_UPDATE_BYTES INT64>>

Esempi di query

Questa sezione include diverse istruzioni SQL di esempio che recuperano le transazioni statistiche. Puoi eseguire queste istruzioni SQL utilizzando librerie client, gcloud spanner, o il Console Google Cloud.

trova il numero totale di tentativi di commit per tutte le transazioni

La seguente query restituisce il numero totale di tentativi di commit per tutti i transazioni nell'ultimo intervallo completo di 1 minuto:

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;
Output query
interval_end commit_attempt_count
2020-01-17 11:46:00-08:00 21

Tieni presente che c'è una sola riga nel risultato perché le statistiche aggregate contengono solo una voce per interval_end per un periodo di tempo qualsiasi.

Trovare la latenza di commit totale in tutte le transazioni

La seguente query restituisce la latenza di commit totale in tutte le transazioni in nei 10 minuti precedenti:

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);
Output query
total_commit_latency_hours
0.8967

Tieni presente che c'è una sola riga nel risultato perché le statistiche aggregate contengono solo una voce per interval_end per un periodo di tempo qualsiasi.

Trovare la latenza al 99° percentile per le transazioni

La seguente query restituisce la latenza del 99° percentile per le transazioni eseguite nei 10 minuti precedenti:

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;
Output query
interval_end avg_total_latency_seconds percentile_latency
2022-08-17 11:46:00-08:00 0.34576998305986395 9.00296190476190476

Nota la grande differenza tra la latenza media e il 99° percentile. La latenza al 99° percentile consente di identificare possibili transazioni outlier con con elevata latenza.

È presente una sola riga nel risultato perché le statistiche aggregate contengono solo una voce per interval_end per un periodo di tempo qualsiasi.

Conservazione dei dati

Spanner conserva i dati di ogni tabella come minimo per il periodo di tempo seguente periodi:

  • SPANNER_SYS.TXN_STATS_TOP_MINUTE e SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: intervalli che coprono i 6 precedenti nell'orario lavorativo locale del TAM.

  • SPANNER_SYS.TXN_STATS_TOP_10MINUTE e SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: intervalli che coprono i 4 precedenti giorni.

  • SPANNER_SYS.TXN_STATS_TOP_HOUR e SPANNER_SYS.TXN_STATS_TOTAL_HOUR: intervalli che coprono i 30 giorni precedenti.

Le statistiche sulle transazioni in Spanner forniscono insight sul modo in cui un'applicazione sta usando il database e sono utili quando si analizzano i problemi di prestazioni. Per Ad esempio, puoi controllare se esistono transazioni a esecuzione lenta che potrebbero essere la causa di contese oppure puoi identificare potenziali fonti di carico elevato ad esempio grandi volumi di aggiornamenti di una determinata colonna. Se utilizzi quanto segue: passaggi, illustreremo come utilizzare le statistiche delle transazioni per effettuare accertamenti contese nel tuo database.

Informazioni sulle transazioni e sui conteggi di commit

Potrebbe essere necessario provare più volte una transazione Spanner prima commit. In genere questo si verifica quando due transazioni di lavorare sugli stessi dati contemporaneamente e una delle transazioni deve essere interrotto per preservare proprietà di isolamento della transazione. Anche altri eventi temporanei che possono causare l'interruzione di una transazione include:

  • Problemi di rete temporanei.

  • Modifiche allo schema del database applicate mentre è in corso una transazione in fase di commit.

  • L'istanza Spanner non ha la capacità di gestire tutti i le richieste che sta ricevendo.

In scenari di questo tipo, un cliente deve riprovare a eseguire la transazione interrotta fino a quando commit correttamente o si verifica il timeout. Per gli utenti del software Spanner ufficiale librerie client, ogni libreria include ha implementato un meccanismo automatico di ripetizione. Se utilizzi una versione personalizzata di aggrega i commit delle transazioni in un loop di nuovi tentativi.

Una transazione Spanner potrebbe anche essere interrotta a causa di un errore non recuperabile ad esempio timeout della transazione, problemi di autorizzazione o una tabella/colonna non valida . Non è necessario riprovare a eseguire queste transazioni e lo Spanner la libreria client restituirà immediatamente l'errore.

La seguente tabella descrive alcuni esempi di come COMMIT_ATTEMPT_COUNT, COMMIT_ABORT_COUNT e COMMIT_RETRY_COUNT hanno eseguito l'accesso in scenari diversi.

Scenario COMMIT_ATTEMPT_COUNT COMMIT_ABORT_COUNT COMMIT_RETRY_COUNT
Commit della transazione eseguita al primo tentativo. 1 0 0
Transazione interrotta a causa di un errore di timeout. 1 1 0
Transazione interrotta a causa di un problema di rete temporaneo e riuscita dopo un nuovo tentativo. 2 1 1
Vengono eseguite 5 transazioni con lo stesso FPRINT entro 10 minuti intervallo di tempo. di 3 transazioni eseguite correttamente al primo tentativo, mentre 2 transazioni sono state interrotte e poi eseguite correttamente primo tentativo. 7 2 2

I dati nelle tabelle delle statistiche sulle transazioni sono dati aggregati relativi a un periodo di tempo intervallo di tempo. Per un determinato intervallo, è possibile che una transazione venga interrotta e riprovare si verifica intorno ai confini e rientrano in bucket diversi. Come il risultato, in un determinato intervallo di tempo, le interruzioni e i nuovi tentativi potrebbero non essere uguali.

Queste statistiche sono pensate per la risoluzione dei problemi e l'introspezione e non è garantita una precisione al 100%. Le statistiche vengono aggregate in memoria prima di essere archiviate nelle tabelle Spanner. Durante un upgrade o un'altra di manutenzione, i server Spanner possono riavviarsi, con ripercussioni l'accuratezza dei numeri.

Risolvi i problemi di contesa dei database utilizzando le statistiche delle transazioni

Puoi utilizzare il codice SQL o lo strumento Transaction Insights dashboard per visualizzare le transazioni nel database che potrebbero causare a causa dei conflitti di blocco.

I seguenti argomenti mostrano come è possibile esaminare queste transazioni utilizzando il codice SQL.

Seleziona un periodo di tempo per l'indagine

Puoi trovarlo nell'applicazione che utilizza Spanner.

Ai fini di questo esercizio, supponiamo che il problema abbia iniziato a verificarsi in intorno alle 17:20 del 17 maggio 2020.

Puoi utilizzare i tag transazione per identificare l'origine della transazione e sono correlate tra le tabelle delle statistiche delle transazioni e quelle di blocco per risoluzione dei problemi di contesa del blocco efficace. Per ulteriori informazioni, consulta la pagina Risoluzione dei problemi relativi ai tag transazione.

Raccogli statistiche sulle transazioni per il periodo di tempo selezionato

Per iniziare l'indagine, eseguiremo una query sulla tabella TXN_STATS_TOTAL_10MINUTE all'inizio del problema. I risultati di questa query ci mostreranno la latenza e le altre statistiche sulle transazioni sono cambiate nel corso del tempo.

Ad esempio, la seguente query restituisce le statistiche aggregate delle transazioni dalle ore 4:30 pm alle ore 7:40 pm (inclusi).

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;

Nella tabella seguente sono elencati i dati di esempio restituiti dalla nostra query.

interval_end avg_total_latency_seconds commit_attempt_count commit_abort_count
17-05-2020 16:40:00-07:00 0,0284 315691 5170
17-05-2020 16:50:00-07:00 0,0250 302124 3828
17-05-2020 17:00:00-07:00 0,0460 346087 11382
17-05-2020 17:10:00-07:00 0,0864 379964 33826
17-05-2020 17:20:00-07:00 0,1291 390343 52.549
17-05-2020 17:30:00-07:00 0,1314 456.455 76.392
17-05-2020 17:40:00-07:00 0,1598 507.774 121.458
17-05-2020 17:50:00-07:00 0,1641 516587 115.875
17-05-2020 18:00:00-07:00 0,1578 552711 122.626
17-05-2020 18:10:00-07:00 0,1750 569.460 154.205
17-05-2020 18:20:00-07:00 0,1727 613.571 160.772
17-05-2020 18:30:00-07:00 0,1588 601994 143.044
17-05-2020 18:40:00-07:00 0,2025 604211 170.019
17-05-2020 18:50:00-07:00 0,1615 601622 135.601
17-05-2020 19:00:00-07:00 0,1653 596.804 129511
17-05-2020 19:10:00-07:00 0,1414 560023 112.247
17-05-2020 19:20:00-07:00 0,1367 570.864 100596
17-05-2020 19:30:00-07:00 0,0894 539729 65316
17-05-2020 19:40:00-07:00 0,0820 479151 40398

Qui vediamo che la latenza aggregata e il numero di interruzioni sono più elevate nei segmenti evidenziati cicli. Possiamo scegliere qualsiasi intervallo di 10 minuti in cui la latenza aggregata il numero di interruzioni e/o interruzioni è elevato. Scegliamo l'intervallo che termina con 2020-05-17T18:40:00 e la useremo nel passaggio successivo per identificare quali transazioni contribuiscono all'alta latenza e al numero di interruzioni.

Identifica le transazioni che stanno avendo una latenza elevata

Ora eseguiamo una query sulla tabella TXN_STATS_TOP_10MINUTE per l'intervallo che è stato scelto nel passaggio precedente. Utilizzando questi dati, possiamo iniziare a identificare quali le transazioni presentano un'elevata latenza e/o un numero di interruzioni elevato.

Esegui questa query per ottenere le principali transazioni che influiscono sulle prestazioni in ordine decrescente di latenza totale per l'intervallo di esempio che termina con 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
17-05-2020 18:40:00-07:00 15185072816865185658 0,3508 0,0139 278.802 142.205 129.884
17-05-2020 18:40:00-07:00 15435530087434255496 0,1633 0,0142 129012 27177 24559
17-05-2020 18:40:00-07:00 14175643543447671202 0,1423 0,0133 5357 636 433
17-05-2020 18:40:00-07:00 898069986622520747 0,0198 0,0158 6 0 0
17-05-2020 18:40:00-07:00 10510121182038036893 0,0168 0,0125 7 0 0
17-05-2020 18:40:00-07:00 9287748709638024175 0,0159 0,0118 4269 1 0
17-05-2020 18:40:00-07:00 7129109266372596045 0,0142 0,0102 182227 0 0
17-05-2020 18:40:00-07:00 15630228555662391800 0,0120 0,0107 58 0 0
17-05-2020 18:40:00-07:00 7907238229716746451 0,0108 0,0097 65 0 0
17-05-2020 18:40:00-07:00 10158167220149989178 0,0095 0,0047 3454 0 0
17-05-2020 18:40:00-07:00 9353100217060788102 0,0093 0,0045 725 0 0
17-05-2020 18:40:00-07:00 9521689070912159706 0,0093 0,0045 164 0 0
17-05-2020 18:40:00-07:00 11079878968512225881 0,0064 0,0019 65 0 0

Vediamo chiaramente che la prima riga (evidenziata) nella tabella precedente mostra una transazione con latenza elevata a causa di un numero elevato di commit viene interrotto. Possiamo anche notare un numero elevato di nuovi tentativi di commit, il che indica i commit interrotti sono stati ritentati. Nel passaggio successivo, esamineremo per capire meglio la causa del problema.

Identificare le colonne coinvolte in una transazione con latenza elevata

In questo passaggio, verificheremo se le transazioni ad alta latenza lo stesso insieme di colonne recuperando read_columns, write_constructive_columns e Dati di write_delete_tables per le transazioni con un numero di interruzioni elevato. FPRINT sarà utile anche nel passaggio successivo.

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] []

Come mostra l'output nella tabella precedente, le transazioni con il la latenza totale media legge le stesse colonne. Possiamo anche osservare alcune poiché le transazioni vengono scritte nella stessa colonna, ovvero per dire TestHigherLatency._exists.

Determinare in che modo il rendimento delle transazioni è cambiato nel tempo

Possiamo osservare l'andamento delle statistiche associate a questa forma di transazione è cambiato in un determinato periodo di tempo. Usa la seguente query, dove $FPRINT è fingerprint della transazione ad alta latenza del passaggio precedente.

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 latenza commit_latency commit_attempt_count commit_abort_count commit_retry_count commit_failed_precondition_count avg_bytes
17-05-2020 16:40:00-07:00 0,095 0,010 53230 4752 4330 0 91
17-05-2020 16:50:00-07:00 0,069 0,009 61264 3589 3364 0 91
17-05-2020 17:00:00-07:00 0,150 0,010 75868 10557 9322 0 91
17-05-2020 17:10:00-07:00 0,248 0,013 103151 30220 28483 0 91
17-05-2020 17:20:00-07:00 0,310 0,012 130078 45655 41966 0 91
17-05-2020 17:30:00-07:00 0,294 0,012 160064 64930 59933 0 91
17-05-2020 17:40:00-07:00 0,315 0,013 209614 104949 96770 0 91
17-05-2020 17:50:00-07:00 0,322 0,012 215682 100408 95867 0 90
17-05-2020 18:00:00-07:00 0,310 0,012 230932 106728 99462 0 91
17-05-2020 18:10:00-07:00 0,309 0,012 259645 131049 125889 0 91
17-05-2020 18:20:00-07:00 0,315 0,013 272171 137910 129411 0 90
17-05-2020 18:30:00-07:00 0,292 0,013 258944 121475 115844 0 91
17-05-2020 18:40:00-07:00 0,350 0,013 278802 142205 134229 0 91
17-05-2020 18:50:00-07:00 0,302 0,013 256259 115626 109756 0 91
17-05-2020 19:00:00-07:00 0,315 0,014 250560 110662 100322 0 91
17-05-2020 19:10:00-07:00 0,271 0,014 238384 99025 90187 0 91
17-05-2020 19:20:00-07:00 0,273 0,014 219687 84019 79874 0 91
17-05-2020 19:30:00-07:00 0,198 0,013 195357 59370 55909 0 91
17-05-2020 19:40:00-07:00 0,181 0,013 167514 35705 32885 0 91

Nell'output riportato sopra, possiamo osservare che la latenza totale è elevata un periodo di tempo. E, ovunque la latenza totale sia elevata, commit_attempt_count Anche commit_abort_count e commit_retry_count sono alti anche se commit la latenza (commit_latency) non è cambiata molto. Dal momento che la transazione viene impegnata vengono interrotti più spesso, i tentativi di commit sono elevati anche eseguire il commit dei nuovi tentativi.

Conclusione

In questo esempio abbiamo visto che un numero elevato di interruzioni del commit è la causa di un una latenza di pochi millisecondi. Il passaggio successivo consiste nell'esaminare i messaggi di errore di interruzione del commit ricevuti all'applicazione per conoscere il motivo dell'interruzione. L'ispezione dei log nel un'applicazione, vediamo che l'applicazione ha cambiato il proprio carico di lavoro durante ad esempio, sono state visualizzate altre forme di transazione con attempts_per_second alto, e che la diversa transazione (forse un job di pulizia notturno) il blocco aggiuntivo è in conflitto.

Identifica le transazioni che non sono state ritentate correttamente

La seguente query restituisce le transazioni campionate negli ultimi dieci minuti con un numero di interruzioni del commit elevato, ma senza nuovi tentativi.

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

Possiamo notare che la transazione con fprint 1557557373282541312 è stata interrotta 44232 volte, ma non è mai stato ripetuto. Sembra sospetto perché l'interruzione è alto ed è improbabile che ogni interruzione sia stata causata da un errore . Invece, per la transazione con fprint 5776062322886969344, è meno sospetto perché il conteggio totale delle interruzioni è non così alto.

La seguente query restituisce ulteriori dettagli sulla transazione con fprint 1557557373282541312 inclusi read_columns,write_constructive_columns, e write_delete_tables. Queste informazioni consentono di identificare la transazione in codice client in cui è possibile esaminare la logica di ripetizione per questo scenario.

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 ["Cantanti._esiste"] ["Singers.FirstName", "Singers.LastName", "Singers._exists"] [] 805228 1839 0
2021-01-27T18:20:00Z 1557557373282541312 ["Cantanti._esiste"] ["Singers.FirstName", "Singers.LastName", "Singers._exists"] [] 1034429 38779 0
2021-01-27T18:10:00Z 1557557373282541312 ["Cantanti._esiste"] ["Singers.FirstName", "Singers.LastName", "Singers._exists"] [] 833677 2266 0
2021-01-27T18:00:00Z 1557557373282541312 ["Cantanti._esiste"] ["Singers.FirstName", "Singers.LastName", "Singers._exists"] [] 694560 1348 0

Possiamo notare che la transazione prevede una lettura degli elementi Singers._exists nascosti per verificare l'esistenza di una riga. La transazione scrive anche Singers.FirstName e Singer.LastName colonne. Queste informazioni possono essere utili determinare se è stato implementato il meccanismo di ripetizione della transazione nel tuo che la libreria client funzioni come previsto.

Passaggi successivi