Statistiche sulle transazioni

Questo documento descrive le statistiche sulle transazioni offerte da Spanner come tabelle integrate. Puoi recuperare le statistiche da queste tabelle SPANNER_SYS.TXN_STATS* utilizzando istruzioni SQL.

Quando utilizzare le statistiche sulle transazioni

Le statistiche sulle transazioni sono utili per analizzare i problemi di rendimento. Ad esempio, puoi verificare se ci sono transazioni lente che potrebbero influire sulle prestazioni o sulle query al secondo (QPS) nel database. Un altro scenario si verifica quando le applicazioni client riscontrano un'elevata latenza di esecuzione delle transazioni. L'analisi delle statistiche sulle transazioni può aiutarti a scoprire potenziali colli di bottiglia, ad esempio grandi volumi di aggiornamenti a una determinata colonna, che potrebbero influire sulla latenza.

Come accedere alle statistiche sulle transazioni

Nota: Spanner Studio (precedentemente etichettato come Query nella console Google Cloud ) supporta le operazioni SQL, DML e DDL in un unico editor. Per ulteriori informazioni, consulta Gestire i dati utilizzando la console Google Cloud .

Spanner fornisce le statistiche sulle transazioni della tabella nello schema SPANNER_SYS. Puoi utilizzare i seguenti modi per accedere ai dati di SPANNER_SYS:

• La pagina Spanner Studio di un database nella console Google Cloud .

• Il comando gcloud spanner databases execute-sql.

• La dashboard Approfondimenti sulle transazioni.

• executeSql o executeStreamingSql.

I seguenti metodi di lettura singola forniti da Spanner non supportano SPANNER_SYS:

• Esecuzione di una lettura coerente da una o più righe di una tabella.
• Esecuzione di una lettura obsoleta da una o più righe di una tabella.
• Lettura da una singola riga o da più righe in un indice secondario.

Statistiche sulla latenza raggruppate per transazione

Le tabelle seguenti monitorano le statistiche per le transazioni che consumano risorse TOP durante un periodo di tempo specifico.

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

• SPANNER_SYS.TXN_STATS_TOP_10MINUTE: statistiche sulle transazioni aggregate a intervalli di 10 minuti.

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

Queste tabelle hanno le seguenti proprietà:

• Ogni tabella contiene dati per intervalli di tempo non sovrapposti della durata specificata dal nome della tabella.

• Gli intervalli sono basati sugli orari

  • Gli intervalli di 1 minuto terminano al minuto.
  • Gli intervalli di 10 minuti terminano ogni 10 minuti a partire dall'ora.
  • Gli intervalli di 1 ora terminano all'ora.

  Ad esempio, alle 11:59:30, gli intervalli più recenti disponibili per le query SQL 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 per FPRINT (impronta) delle transazioni. Se è presente un tag transazione, FPRINT è l'hash del tag. In caso contrario, è l'hash calcolato in base alle operazioni coinvolte nella transazione.

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

• Ogni riga contiene statistiche per tutte le esecuzioni di una determinata transazione per cui Spanner acquisisce 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 la latenza, i tentativi di commit e i byte scritti più elevati durante l'intervallo specificato.

• Tutte le colonne delle tabelle sono annullabili.

Schema tabella

Nome colonna	Tipo	Descrizione
INTERVAL_END	TIMESTAMP	Fine dell'intervallo di tempo in cui si sono verificate le esecuzioni delle transazioni incluse.
TRANSACTION_TAG	STRING	Il tag di transazione facoltativo per questa operazione di transazione. Per saperne di più sull'utilizzo dei tag, consulta Risoluzione dei problemi con i tag transazione. Le statistiche per più transazioni con la stessa stringa tag sono raggruppate in una singola riga con `TRANSACTION_TAG` corrispondente a quella stringa tag.
FPRINT	INT64	L'hash di TRANSACTION_TAG, se presente; in caso contrario, l'hash viene calcolato in base alle operazioni coinvolte nella transazione. INTERVAL_END e FPRINT insieme fungono da chiave univoca per queste tabelle.
READ_COLUMNS	ARRAY<STRING>	L'insieme di colonne lette dalla transazione.
WRITE_CONSTRUCTIVE_COLUMNS	ARRAY<STRING>	Il set di colonne scritte in modo costruttivo, a cui vengono assegnati nuovi valori, dalla transazione. Per modifiche in tempo reale, se la transazione ha comportato scritture in colonne e tabelle monitorate da uno stream di modifiche, WRITE_CONSTRUCTIVE_COLUMNS contiene due colonne: .data e ._exists , con il prefisso del nome dello stream di modifiche. _exists è un campo utilizzato per verificare se una determinata riga esiste o meno.
WRITE_DELETE_TABLES	ARRAY<STRING>	Il set di tabelle le cui righe sono state eliminate o sostituite dalla transazione.
ATTEMPT_COUNT	INT64	Numero totale di tentativi di transazione, inclusi quelli interrotti prima di chiamare `commit`.
COMMIT_ATTEMPT_COUNT	INT64	Numero totale di tentativi di commit delle transazioni. Deve corrispondere al numero di chiamate al metodo commit della transazione.
COMMIT_ABORT_COUNT	INT64	Numero totale di tentativi di transazione interrotti, inclusi quelli interrotti prima di chiamare il metodo commit della transazione.
COMMIT_RETRY_COUNT	INT64	Numero totale di tentativi che sono nuovi tentativi di tentativi interrotti in precedenza. Una transazione Spanner potrebbe essere tentata più volte prima di essere eseguita a causa di contese di blocco o eventi temporanei. Un numero elevato di tentativi rispetto ai tentativi di commit indica che potrebbero esserci problemi da esaminare. Per saperne di più, consulta la sezione Informazioni su transazioni e conteggi dei commit in questa pagina.
COMMIT_FAILED_PRECONDITION_COUNT	INT64	Numero totale di tentativi di commit delle transazioni che hanno restituito errori di precondizione non riusciti, ad esempio violazioni dell'indice UNIQUE, riga già esistente o riga non trovata.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT	INT64	Numero totale di tentativi di transazione avviati con il SERIALIZABLE livello di isolamento e il blocco PESSIMISTIC. È un sottoinsieme di ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT	INT64	Numero totale di tentativi di transazione avviati con il REPEATABLE READ livello di isolamento e il blocco OPTIMISTIC. È un sottoinsieme di ATTEMPT_COUNT.
AVG_PARTICIPANTS	FLOAT64	Numero medio di partecipanti in ogni tentativo di commit. Per saperne di più sui partecipanti, vedi Durata di letture e scritture di Spanner.
AVG_TOTAL_LATENCY_SECONDS	FLOAT64	Media dei secondi impiegati dalla prima operazione della transazione al commit/interruzione.
AVG_COMMIT_LATENCY_SECONDS	FLOAT64	Media dei 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 totale del commit, ovvero il tempo che intercorre tra l'ora di inizio della prima operazione transazionale e l'ora di commit o di interruzione, per tutti i tentativi di una transazione. Nota sull'interfaccia PostgreSQL: I database di dialetti PostgreSQL non supportano questa colonna. Utilizza invece la colonna TOTAL_LATENCY_DISTRIBUTION_JSON_STRING per i database di dialetti PostgreSQL. Se una transazione viene interrotta più volte e poi viene eseguita correttamente, la latenza viene misurata per ogni tentativo fino all'esecuzione finale riuscita. I valori sono misurati in secondi. L'array contiene un singolo elemento e ha 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 ed Esponenziale. Per calcolare la latenza percentile dalla distribuzione, utilizza la funzione SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), che restituisce l'n° percentile stimato. Per un esempio correlato, vedi Trovare la latenza del 99° percentile per le transazioni. Per saperne di più, consulta Percentili e metriche con valori di distribuzione.
OPERATIONS_BY_TABLE	ARRAY<STRUCT>	Impatto delle operazioni INSERT o UPDATE in base alla transazione per tabella. Ciò è indicato dal numero di volte in cui le righe sono interessate e dal numero di byte scritti. Nota sull'interfaccia PostgreSQL: I database di dialetti PostgreSQL non supportano questa colonna. Utilizza invece la colonna OPERATIONS_BY_TABLE_JSON_STRING per i database di dialetti PostgreSQL. Questa colonna consente di visualizzare il carico sulle tabelle e fornisce informazioni sul tasso di scrittura di una transazione nelle tabelle. Specifica l'array nel seguente modo: ARRAY<STRUCT<   TABLE STRING(MAX),   INSERT_OR_UPDATE_COUNT INT64,   INSERT_OR_UPDATE_BYTES INT64>>
TOTAL_LATENCY_DISTRIBUTION_JSON_STRING	STRING	Un istogramma della latenza totale del commit, ovvero il tempo che intercorre tra l'ora di inizio della prima operazione transazionale e l'ora di commit o di interruzione, per tutti i tentativi di una transazione. Una rappresentazione di stringa compatibile con JSON della statistica TOTAL_LATENCY_DISTRIBUTION. La stringa JSON è un oggetto JSON con la stessa struttura dello STRUCT definito in TOTAL_LATENCY_DISTRIBUTION. Se una transazione viene interrotta più volte e poi viene eseguita correttamente, la latenza viene misurata per ogni tentativo fino all'esecuzione finale riuscita. I valori sono misurati in secondi. Questa colonna è supportata nei database con dialetto GoogleSQL e PostgreSQL. Questa colonna contiene la distribuzione. Per calcolare la latenza percentile dalla distribuzione, utilizza la funzione SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), che restituisce l'n° percentile stimato. Per un esempio correlato, vedi Trovare la latenza del 99° percentile per le transazioni utilizzando la colonna TOTAL_LATENCY_DISTRIBUTION_JSON_STRING. Per saperne di più, consulta Percentili e metriche con valori di distribuzione.
OPERATIONS_BY_TABLE_JSON_STRING	STRING	Impatto delle operazioni INSERT o UPDATE in base alla transazione per tabella. Ciò è indicato dal numero di volte in cui le righe sono interessate e dal numero di byte scritti. Una rappresentazione di stringa compatibile con JSON della colonna OPERATIONS_BY_TABLE. La stringa JSON è un oggetto JSON con la stessa struttura dello STRUCT definito nella colonna OPERATIONS_BY_TABLE. Questa colonna è supportata nei database con dialetto GoogleSQL e PostgreSQL. Questa colonna consente di visualizzare il carico sulle tabelle e fornisce informazioni sul tasso di scrittura di una transazione nelle tabelle.

Esempi di query

Questa sezione include diversi esempi di istruzioni SQL che recuperano le statistiche sulle transazioni. Puoi eseguire queste istruzioni SQL utilizzando le librerie client, gcloud spanner o la consoleGoogle 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 nel 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 della 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 latenza di commit media più elevata

La seguente query restituisce le transazioni con latenza di commit media elevata nell'ora precedente, ordinate 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 della 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 1 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 della 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 in base al 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 della 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 per tutte le transazioni per le quali Spanner ha acquisito 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 durante 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 specificata dal nome della tabella.

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

  Ad esempio, alle 11:59:30, gli intervalli più recenti disponibili per le query SQL 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 di tutte le transazioni eseguite nel database durante l'intervallo specificato, aggregate. È presente una sola riga per intervallo di tempo.

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

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

  • Numero di tentativi di commit
  • Conteggio dei nuovi tentativi di commit
  • Partecipanti alle transazioni
  • Latenze transazione
  • Byte scritti

  Per saperne di più, consulta Metriche di Spanner.

Schema tabella

Nome colonna	Tipo	Descrizione
INTERVAL_END	TIMESTAMP	Fine dell'intervallo di tempo in cui è stata acquisita questa statistica.
ATTEMPT_COUNT	INT64	Numero totale di tentativi di transazione, inclusi quelli interrotti prima di chiamare `commit`.
COMMIT_ATTEMPT_COUNT	INT64	Numero totale di tentativi di commit delle transazioni. Deve corrispondere al numero di chiamate al metodo commit della transazione.
COMMIT_ABORT_COUNT	INT64	Numero totale di tentativi di transazione interrotti, inclusi quelli interrotti prima di chiamare il metodo commit della transazione.
COMMIT_RETRY_COUNT	INT64	Numero di tentativi di commit che sono nuovi tentativi di tentativi precedentemente interrotti. Una transazione Spanner potrebbe essere stata tentata più volte prima di essere eseguita a causa di contese di blocco o eventi temporanei. Un numero elevato di tentativi rispetto ai tentativi di commit indica che potrebbero esserci problemi da esaminare. Per saperne di più, consulta la sezione Informazioni su transazioni e conteggi dei commit in questa pagina.
COMMIT_FAILED_PRECONDITION_COUNT	INT64	Numero totale di tentativi di commit delle transazioni che hanno restituito errori di precondizione non riuscita, come violazioni dell'indice UNIQUE, riga già esistente o riga non trovata.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT	INT64	Numero totale di tentativi di transazione avviati con il livello di isolamento SERIALIZABLE e il blocco PESSIMISTIC. È un sottoinsieme di ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT	INT64	Numero totale di tentativi di transazione avviati con il livello di isolamento REPEATABLE READ e il blocco OPTIMISTIC. È un sottoinsieme di ATTEMPT_COUNT.
AVG_PARTICIPANTS	FLOAT64	Numero medio di partecipanti in ogni tentativo di commit. Per saperne di più sui partecipanti, vedi Durata di letture e scritture di Spanner.
AVG_TOTAL_LATENCY_SECONDS	FLOAT64	Media dei secondi impiegati dalla prima operazione della transazione al commit/interruzione.
AVG_COMMIT_LATENCY_SECONDS	FLOAT64	Media dei 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 totale di commit, ovvero il tempo che intercorre tra l'ora di inizio della prima operazione transazionale e l'ora di commit o interruzione per tutti i tentativi di transazione. Nota sull'interfaccia PostgreSQL: I database di dialetti PostgreSQL non supportano questa colonna. Utilizza invece la colonna TOTAL_LATENCY_DISTRIBUTION_JSON_STRING per i database di dialetto PostgreSQL. Se una transazione viene interrotta più volte e poi viene eseguita correttamente, la latenza viene misurata per ogni tentativo fino all'esecuzione finale riuscita. I valori sono misurati in secondi. L'array contiene un singolo elemento e ha 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 ed Esponenziale. Per calcolare la latenza percentile dalla distribuzione, utilizza la funzione SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), che restituisce l'n° percentile stimato. Per un esempio, vedi Trovare la latenza del 99° percentile per le transazioni. Per saperne di più, consulta Percentili e metriche con valori di distribuzione.
OPERATIONS_BY_TABLE	ARRAY<STRUCT>	Impatto delle operazioni INSERT o UPDATE per tutte le transazioni in base alla tabella. Ciò è indicato dal numero di volte in cui le righe sono interessate e dal numero di byte scritti. Nota sull'interfaccia PostgreSQL: I database di dialetti PostgreSQL non supportano questa colonna. Utilizza invece la colonna OPERATIONS_BY_TABLE_JSON_STRING per i database di dialetto PostgreSQL. Questa colonna consente di visualizzare il carico sulle tabelle e fornisce informazioni sul tasso di scrittura delle transazioni nelle tabelle. Specifica l'array nel seguente modo: ARRAY<STRUCT<   TABLE STRING(MAX),   INSERT_OR_UPDATE_COUNT INT64,   INSERT_OR_UPDATE_BYTES INT64>>
TOTAL_LATENCY_DISTRIBUTION_JSON_STRING	STRING	Un istogramma della latenza totale del commit, ovvero il tempo che intercorre tra l'ora di inizio della prima operazione transazionale e l'ora di commit o di interruzione, per tutti i tentativi di una transazione. Una rappresentazione di stringa compatibile con JSON della statistica TOTAL_LATENCY_DISTRIBUTION. La stringa JSON è un oggetto JSON con la stessa struttura dello STRUCT definito in TOTAL_LATENCY_DISTRIBUTION. Se una transazione viene interrotta più volte e poi viene eseguita correttamente, la latenza viene misurata per ogni tentativo fino all'esecuzione finale riuscita. I valori sono misurati in secondi. Questa colonna è supportata nei database con dialetto GoogleSQL e PostgreSQL. Questa colonna contiene la distribuzione. Per calcolare la latenza percentile dalla distribuzione, utilizza la funzione SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), che restituisce l'n° percentile stimato. Per un esempio correlato, vedi Trovare la latenza del 99° percentile per le transazioni utilizzando la colonna TOTAL_LATENCY_DISTRIBUTION_JSON_STRING. Per saperne di più, consulta Percentili e metriche con valori di distribuzione.
OPERATIONS_BY_TABLE_JSON_STRING	STRING	Impatto delle operazioni INSERT o UPDATE in base alla transazione per tabella. Ciò è indicato dal numero di volte in cui le righe sono interessate e dal numero di byte scritti. Una rappresentazione di stringa compatibile con JSON della colonna OPERATIONS_BY_TABLE. La stringa JSON è un oggetto JSON con la stessa struttura dello STRUCT definito nella colonna OPERATIONS_BY_TABLE. Questa colonna è supportata nei database con dialetto GoogleSQL e PostgreSQL. Questa colonna consente di visualizzare il carico sulle tabelle e fornisce informazioni sul tasso di scrittura di una transazione nelle tabelle.

Esempi di query

Questa sezione include diversi esempi di istruzioni SQL che recuperano le statistiche sulle transazioni. Puoi eseguire queste istruzioni SQL utilizzando le librerie client, gcloud spanner o la consoleGoogle 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 tutte le transazioni nell'intervallo di 1 minuto completo più recente:

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 della query

interval_end	commit_attempt_count
2020-01-17 11:46:00-08:00	21

Tieni presente che nel risultato è presente una sola riga perché le statistiche aggregate hanno una sola voce per interval_end per qualsiasi durata di tempo.

Trovare la latenza totale di commit in tutte le transazioni

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

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 della query

total_commit_latency_hours
0.8967

Tieni presente che nel risultato è presente una sola riga perché le statistiche aggregate hanno una sola voce per interval_end per qualsiasi durata di tempo.

Trovare la latenza del 99° percentile per le transazioni

Le seguenti query restituiscono il 99° percentile del tempo di esecuzione per le query eseguite nei 10 minuti precedenti.

Per i database con dialetto GoogleSQL, puoi utilizzare la colonna 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;

Per i database di dialetti PostgreSQL, utilizza invece la colonna 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;

Output della 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 quella del 99° percentile. La latenza del 99° percentile aiuta a identificare le possibili transazioni outlier con latenza elevata.

Nel risultato è presente una sola riga perché le statistiche aggregate hanno una sola voce per interval_end per qualsiasi durata.

Conservazione dei dati

Come minimo, Spanner conserva i dati per ogni tabella per i seguenti periodi di tempo:

• SPANNER_SYS.TXN_STATS_TOP_MINUTE e SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Intervalli che coprono le 6 ore precedenti.

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

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

Nota: non puoi impedire a Spanner di raccogliere statistiche sulle transazioni. Per eliminare i dati in queste tabelle, devi eliminare il database associato alle tabelle o attendere che Spanner rimuova i dati automaticamente. Non puoi estendere il periodo di conservazione per queste tabelle.

Le statistiche sulle transazioni in Spanner forniscono informazioni su come un'applicazione utilizza il database e sono utili per analizzare i problemi di rendimento. Ad esempio, puoi verificare se sono presenti transazioni a esecuzione lenta che potrebbero causare contese oppure puoi identificare potenziali origini di carico elevato, ad esempio grandi volumi di aggiornamenti a una determinata colonna.

Comprendere le transazioni e i conteggi dei commit

Una transazione Spanner potrebbe dover essere provata più volte prima di essere eseguita. Ciò si verifica più comunemente quando due transazioni tentano di operare sugli stessi dati contemporaneamente e una delle transazioni deve essere interrotta per preservare la proprietà di isolamento della transazione. Altri eventi temporanei che possono anche causare l'interruzione di una transazione includono:

• Problemi di rete temporanei.

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

• L'istanza Spanner non ha la capacità di gestire tutte le richieste che riceve.

In questi scenari, un client deve riprovare la transazione interrotta finché non viene eseguita correttamente o non scade il timeout. Per gli utenti delle librerie client ufficiali di Spanner, ogni libreria ha implementato un meccanismo di riprova automatica. Se utilizzi una versione personalizzata del codice client, racchiudi i commit delle transazioni in un ciclo di nuovi tentativi.

Una transazione Spanner può essere interrotta anche a causa di un errore non ripristinabile come un timeout della transazione, problemi di autorizzazione o un nome di tabella o colonna non valido. Non è necessario riprovare a eseguire queste transazioni e la libreria client Spanner restituirà immediatamente l'errore.

La tabella seguente descrive alcuni esempi di come vengono registrati COMMIT_ATTEMPT_COUNT, COMMIT_ABORT_COUNT e COMMIT_RETRY_COUNT in diversi scenari.

Scenario	COMMIT_ATTEMPT_COUNT	COMMIT_ABORT_COUNT	COMMIT_RETRY_COUNT
Transazione eseguita correttamente 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 avviata correttamente dopo un tentativo.	2	1	1
5 transazioni con lo stesso FPRINT vengono eseguite entro un intervallo di 10 minuti. 3 delle transazioni sono state eseguite correttamente al primo tentativo, mentre 2 transazioni sono state interrotte e poi eseguite correttamente al primo tentativo.	7	2	2

I dati nelle tabelle transactions-stats sono dati aggregati per un intervallo di tempo. Per un determinato intervallo, è possibile che un'interruzione e un nuovo tentativo di transazione si verifichino intorno ai limiti e rientrino in bucket diversi. Di conseguenza, in un determinato intervallo di tempo gli annullamenti e i tentativi potrebbero non essere uguali.

Queste statistiche sono progettate per la risoluzione dei problemi e l'introspezione e non è garantita la loro accuratezza al 100%. Le statistiche vengono aggregate in memoria prima di essere memorizzate nelle tabelle Spanner. Durante un upgrade o altre attività di manutenzione, i server Spanner possono riavviarsi, influendo sull'accuratezza dei numeri.

Risolvere i problemi di contesa del database utilizzando le statistiche sulle transazioni

Puoi utilizzare il codice SQL o la dashboard Approfondimenti sulle transazioni per visualizzare le transazioni nel tuo database che potrebbero causare latenze elevate a causa di contese di blocco.

Gli argomenti seguenti mostrano come esaminare queste transazioni utilizzando il codice SQL.

Seleziona un periodo di tempo da esaminare

Può essere trovato nell'applicazione che utilizza Spanner.

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

Puoi utilizzare i tag transazione per identificare l'origine della transazione e correlare la tabella delle statistiche delle transazioni e le tabelle delle statistiche dei blocchi per una risoluzione efficace dei problemi di contesa dei blocchi. Scopri di più in Risoluzione dei problemi con i tag transazione.

Raccogli le statistiche sulle transazioni per il periodo di tempo selezionato

Per avviare l'indagine, esegui una query sulla tabella TXN_STATS_TOTAL_10MINUTE intorno all'inizio del problema. I risultati di questa query mostrano come la latenza e altre statistiche sulle transazioni sono cambiate in questo periodo di tempo.

Ad esempio, la seguente query restituisce le statistiche aggregate sulle transazioni dal giorno 4:30 pm al giorno 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;

La tabella seguente elenca i dati di esempio restituiti dalla query.

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 latenza aggregata e il conteggio degli annullamenti sono più elevati nei periodi evidenziati. Scegli un intervallo di 10 minuti in cui la latenza aggregata e il conteggio degli errori o entrambi sono elevati. L'intervallo che termina alle 2020-05-17T18:40:00 viene utilizzato nel passaggio successivo per identificare quali transazioni contribuiscono a un conteggio elevato di latenza e interruzioni.

Identificare le transazioni che registrano una latenza elevata

Esegui una query sulla tabella TXN_STATS_TOP_10MINUTE per l'intervallo selezionato nel passaggio precedente. Utilizzando questi dati, puoi iniziare a identificare le transazioni che riscontrano latenza elevata o un numero elevato di interruzioni o entrambe.

Esegui la seguente query per ottenere le transazioni con il maggiore impatto sulle prestazioni in ordine decrescente di latenza totale per l'intervallo di esempio che termina alle 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 prima riga (evidenziata) della tabella precedente mostra una transazione con latenza elevata a causa di un numero elevato di interruzioni del commit. Inoltre, è presente un numero elevato di tentativi di commit, il che indica che i commit interrotti sono stati successivamente ritentati. Il passaggio successivo esamina ulteriormente per capire la causa del problema.

Identificare le colonne coinvolte in una transazione con latenza elevata

In questo passaggio, controlla se le transazioni ad alta latenza operano sullo stesso insieme di colonne recuperando i dati read_columns, write_constructive_columns e write_delete_tables per le transazioni con un numero elevato di interruzioni. Il valore 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 mostrato nell'output della tabella precedente, le transazioni con la latenza totale media più elevata leggono le stesse colonne. Esiste anche una contesa di scrittura, poiché le transazioni scrivono nella stessa colonna, ovvero TestHigherLatency._exists.

Determinare come è cambiato il rendimento delle transazioni nel tempo

Puoi vedere come sono cambiate le statistiche associate a questa forma della transazione in un periodo di tempo. Utilizza la seguente query, dove $FPRINT è l'impronta della transazione con latenza elevata 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
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

In questo output osserva che la latenza totale è elevata per il periodo di tempo evidenziato. Inoltre, ovunque la latenza totale sia elevata, anche commit_attempt_count, commit_abort_count e commit_retry_count sono elevati, anche se la latenza di commit (commit_latency) non è cambiata molto. Poiché i commit delle transazioni vengono interrotti più frequentemente, anche i tentativi di commit sono elevati a causa dei nuovi tentativi di commit.

Conclusione

In questo esempio, il numero elevato di interruzioni del commit è stato la causa dell'elevata latenza. Il passaggio successivo consiste nell'esaminare i messaggi di errore di interruzione del commit ricevuti dall'applicazione per conoscere il motivo delle interruzioni. Ispezionando i log nell'applicazione, puoi notare che l'applicazione ha effettivamente modificato il carico di lavoro durante questo periodo di tempo, ovvero è apparsa un'altra forma di transazione con un valore di attempts_per_second elevato e che questa transazione diversa (forse un'attività di pulizia notturna) è stata responsabile dei conflitti di blocco aggiuntivi.

Identificare le transazioni per le quali non è stato eseguito correttamente un nuovo tentativo

La seguente query restituisce le transazioni campionate negli ultimi 10 minuti che hanno un numero elevato di interruzioni del commit, ma nessun tentativo.

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 transazione con l'impronta 1557557373282541312 è stata interrotta 44232 volte, ma non è mai stata riprovata. Questo sembra sospetto perché il conteggio degli errori di interruzione è elevato ed è improbabile che ogni interruzione sia stata causata da un errore non riproducibile. D'altra parte, per la transazione con impronta 5776062322886969344, la situazione è meno sospetta perché il conteggio totale degli annullamenti non è così elevato.

La seguente query restituisce maggiori dettagli sulla transazione con impronta 1557557373282541312,inclusi read_columns, write_constructive_columns e write_delete_tables. Queste informazioni aiutano a identificare la transazione nel codice client, dove la logica di ripetizione può essere esaminata 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	['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 transazione prevede una lettura della colonna nascosta Singers._exists per verificare l'esistenza di una riga. La transazione scrive anche nelle colonne Singers.FirstName e Singer.LastName. Queste informazioni possono aiutarti a determinare se il meccanismo di ripetizione delle transazioni implementato nella tua libreria client personalizzata funziona come previsto.

Passaggi successivi

• Scopri di più su altri strumenti di introspezione.
• Scopri di più sulle altre informazioni memorizzate da Spanner per ogni database nelle tabelle dello schema informativo del database.
• Scopri di più sulle best practice per SQL per Spanner.
• Scopri di più su come analizzare l'utilizzo elevato della CPU.