Cloud Spanner offre tabelle integrate che mantengono molte statistiche per le query e le istruzioni DML che hanno utilizzato la maggior parte della CPU, oltre a tutte le query in aggregato (incluse le query stream stream).
Disponibilità
I dati SPANNER_SYS
sono disponibili solo tramite le interfacce SQL; ad esempio:
La pagina Query di un database nella console Google Cloud
Il comando
gcloud spanner databases execute-sql
Dashboard di Query Insights
API
executeQuery
Altri metodi di lettura singola forniti da Spanner non supportano SPANNER_SYS
.
Utilizzo CPU raggruppato per query
Le seguenti tabelle monitorano le query con il massimo utilizzo di CPU durante un periodo di tempo specifico:
SPANNER_SYS.QUERY_STATS_TOP_MINUTE
: query durante intervalli di 1 minutoSPANNER_SYS.QUERY_STATS_TOP_10MINUTE
: query a intervalli di 10 minutiSPANNER_SYS.QUERY_STATS_TOP_HOUR
: query durante intervalli di 1 ora
Queste tabelle hanno le seguenti proprietà:
Ogni tabella contiene dati relativi a intervalli di tempo non sovrapposti della lunghezza specificata dal nome della tabella.
Gli intervalli si basano sull'ora dell'orologio. Gli intervalli di 1 minuto terminano sul minuto, gli intervalli di 10 minuti terminano ogni 10 minuti a partire dall'ora e gli intervalli di 1 ora terminano l'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 in base al testo della query SQL. Se una query utilizza parametri di ricerca, Spanner raggruppa tutte le esecuzioni della query in una riga. Se la query utilizza valori letterali di stringa, Spanner raggruppa le statistiche solo se il testo completo della query è identico; quando un testo è diverso, ogni query viene visualizzata come riga separata. Per il DML del batch, Spanner normalizza il batch deduplicando istruzioni identiche consecutive prima di generare l'impronta.
Se è presente un tag di richiesta, FPRINT è l'hash del tag di richiesta. In caso contrario, è l'hash del valore
TEXT
.Ogni riga contiene le statistiche relative a tutte le esecuzioni di una determinata query SQL per cui Spanner acquisisce le statistiche durante l'intervallo specificato.
Se Spanner non è in grado di archiviare tutte le query eseguite durante l'intervallo, il sistema dà la priorità alle query con il massimo utilizzo della CPU durante l'intervallo specificato.
Le query monitorate includono quelle completate, non riuscite o annullate dall'utente.
Un sottoinsieme di statistiche è specifico per le query eseguite ma che non sono state completate:
Conteggio e latenza media in secondi per tutte le query che non sono andate a buon fine.
Conteggio dell'esecuzione per le query scadute.
Conteggio dell'esecuzione per le query annullate dall'utente o non riuscite a causa di problemi di connettività di rete.
Schema tabella
Nome colonna | Tipo | Descrizione | |
---|---|---|---|
INTERVAL_END |
TIMESTAMP |
Fine dell'intervallo di tempo in cui si sono verificate le esecuzioni delle query incluse. | |
REQUEST_TAG |
STRING |
Il tag di richiesta facoltativo per questa operazione di query. Per scoprire di più sull'utilizzo dei tag, consulta la pagina Risoluzione dei problemi relativi ai tag di richiesta. | |
TEXT |
STRING |
Testo della query SQL, troncato a circa 64 kB.
Le statistiche relative a più query che hanno la stessa stringa tag vengono raggruppate in una singola riga con la REQUEST_TAG corrispondente a quella stringa tag. In questo campo viene mostrato solo il testo di una di queste query, troncato a circa 64 kB.
Per i DML batch, l'insieme di istruzioni SQL è suddiviso in una singola riga, concatenata usando un delimitatore di punto e virgola. I testi SQL identici consecutivi vengono deduplicati prima di troncarli.
|
|
TEXT_TRUNCATED |
BOOL |
Indica se il testo della query è stato troncato. | |
TEXT_FINGERPRINT |
INT64 |
L'hash del valore REQUEST_TAG se presente; in caso contrario, l'hash del valore TEXT . |
|
EXECUTION_COUNT |
INT64 |
Numero di volte in cui Cloud Spanner ha visualizzato la query durante l'intervallo. | |
AVG_LATENCY_SECONDS |
FLOAT64 |
Durata media, in secondi, di ogni esecuzione della query all'interno del database. Questa media esclude il tempo di codifica e trasmissione per il set di risultati e l'overhead. | |
AVG_ROWS |
FLOAT64 |
Numero medio di righe restituite dalla query. | |
AVG_BYTES |
FLOAT64 |
Numero medio di byte di dati restituiti dalla query, tranne l'overhead di codifica della trasmissione. | |
AVG_ROWS_SCANNED |
FLOAT64 |
Numero medio di righe scansionate dalla query, esclusi i valori eliminati. | |
AVG_CPU_SECONDS |
FLOAT64 |
Numero medio di secondi di tempo di CPU dedicati da Cloud Spanner a tutte le operazioni per l'esecuzione della query. | |
ALL_FAILED_EXECUTION_COUNT |
INT64 |
Numero di volte in cui la query non è andata a buon fine durante l'intervallo. | |
ALL_FAILED_AVG_LATENCY_SECONDS |
FLOAT64 |
Durata media, in secondi, di ogni esecuzione della query non riuscita nel database. Questa media esclude il tempo di codifica e trasmissione per il set di risultati e l'overhead. | |
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT |
INT64 |
Il numero di volte in cui la query è stata annullata dall'utente o non riuscita a causa di una connessione di rete interrotta durante l'intervallo. | |
TIMED_OUT_EXECUTION_COUNT |
INT64 |
Numero di timeout della query durante l'intervallo. | |
AVG_BYTES_WRITTEN |
FLOAT64 |
Numero medio di byte scritti dall'istruzione. | |
AVG_ROWS_WRITTEN |
FLOAT64 |
Numero medio di righe modificate dall'istruzione. | |
STATEMENT_COUNT |
INT64 |
La somma delle istruzioni aggregate in questa voce. Per le query normali e il DML, questo corrisponde al numero di esecuzioni. Per il DML batch, Spanner acquisisce il numero di istruzioni nel batch. | |
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT |
INT64 |
Il numero di volte in cui la query è stata eseguita nell'ambito di una transazione di lettura-scrittura. Questa colonna consente di determinare se è possibile evitare contese bloccando lo spostamento della query in una transazione di sola lettura. | |
LATENCY_DISTRIBUTION |
ARRAY<STRUCT> |
Un istogramma del tempo di esecuzione della query. I valori vengono misurati in secondi.
L'array contiene un singolo elemento e ha il seguente tipo:
Per calcolare la latenza percentile desiderata dalla distribuzione, utilizza la funzione Per saperne di più, vedi Percentile e metriche con valore di distribuzione. |
EXECUTION_COUNT
, AVG_LATENCY_SECONDS
e LATENCY_DISTRIBUTION
per le query non riuscite includono le query non riuscite a causa di una sintassi errata o che hanno riscontrato un errore temporaneo, ma che sono riuscite a riprovare.
Statistiche aggregate
Sono inoltre disponibili tabelle che tracciano i dati aggregati per tutte le query per cui Spanner ha acquisito statistiche in un periodo di tempo specifico:
SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE
: query durante intervalli di 1 minutoSPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE
: query a intervalli di 10 minutiSPANNER_SYS.QUERY_STATS_TOTAL_HOUR
: query durante intervalli di 1 ora
Queste tabelle hanno le seguenti proprietà:
Ogni tabella contiene dati relativi a intervalli di tempo non sovrapposti della lunghezza specificata dal nome della tabella.
Gli intervalli si basano sull'ora dell'orologio. Gli intervalli di 1 minuto terminano sul minuto, gli intervalli di 10 minuti terminano ogni 10 minuti a partire dall'ora e gli intervalli di 1 ora terminano l'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
Ogni riga contiene statistiche per tutte le query eseguite sul database durante l'intervallo specificato, aggregate insieme. Esiste una sola riga per intervallo di tempo e include le query completate, quelle non riuscite e quelle annullate dall'utente.
Le statistiche acquisite nelle tabelle
TOTAL
potrebbero includere query che Spanner non ha acquisito nelle tabelleTOP
.Alcune colonne di queste tabelle sono esposte come metriche in Cloud Monitoring. Le metriche esposte sono:
- Conteggio esecuzione query
- Query non riuscite
- Latenze di query
- Conteggio delle righe restituite
- Conteggio delle righe scansionate
- Numero di byte restituiti
- Query su tempo di CPU
Per saperne di più, vedi Metriche di Spanner.
Schema tabella
Nome colonna | Tipo | Descrizione |
---|---|---|
INTERVAL_END |
TIMESTAMP |
Fine dell'intervallo di tempo in cui si sono verificate le esecuzioni delle query incluse. |
EXECUTION_COUNT |
INT64 |
Numero di volte in cui Cloud Spanner ha visualizzato la query durante l'intervallo di tempo. |
AVG_LATENCY_SECONDS |
FLOAT64 |
Durata media, in secondi, di ogni esecuzione della query all'interno del database. Questa media esclude il tempo di codifica e trasmissione per il set di risultati e l'overhead. |
AVG_ROWS |
FLOAT64 |
Numero medio di righe restituite dalla query. |
AVG_BYTES |
FLOAT64 |
Numero medio di byte di dati restituiti dalla query, tranne l'overhead di codifica della trasmissione. |
AVG_ROWS_SCANNED |
FLOAT64 |
Numero medio di righe scansionate dalla query, esclusi i valori eliminati. |
AVG_CPU_SECONDS |
FLOAT64 |
Numero medio di secondi di tempo di CPU dedicati da Cloud Spanner a tutte le operazioni per l'esecuzione della query. |
ALL_FAILED_EXECUTION_COUNT |
INT64 |
Numero di volte in cui la query non è andata a buon fine durante l'intervallo. |
ALL_FAILED_AVG_LATENCY_SECONDS |
FLOAT64 |
Durata media, in secondi, di ogni esecuzione della query non riuscita nel database. Questa media esclude il tempo di codifica e trasmissione per il set di risultati e l'overhead. |
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT |
INT64 |
Il numero di volte in cui la query è stata annullata dall'utente o non riuscita a causa di una connessione di rete interrotta durante l'intervallo. |
TIMED_OUT_EXECUTION_COUNT |
INT64 |
Numero di timeout della query durante l'intervallo. |
AVG_BYTES_WRITTEN |
FLOAT64 |
Numero medio di byte scritti dall'istruzione. |
AVG_ROWS_WRITTEN |
FLOAT64 |
Numero medio di righe modificate dall'istruzione. |
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT |
INT64 |
Il numero di volte in cui le query sono state eseguite nell'ambito di transazioni di lettura/scrittura. Questa colonna consente di determinare se puoi evitare le contese spostando alcune query in transazioni di sola lettura. |
LATENCY_DISTRIBUTION |
ARRAY<STRUCT> |
Un istogramma del tempo di esecuzione tra le query. I valori sono misurati in secondi.
Specifica l'array come segue:
Per calcolare la latenza percentile desiderata dalla distribuzione, utilizza la funzione Per saperne di più, vedi Percentile e metriche con valore di distribuzione. |
Conservazione dei dati
Come minimo, Spanner conserva i dati per ogni tabella per i seguenti periodi di tempo:
SPANNER_SYS.QUERY_STATS_TOP_MINUTE
eSPANNER_SYS.QUERY_STATS_TOTAL_MINUTE
: intervalli che coprono le 6 ore precedenti.SPANNER_SYS.QUERY_STATS_TOP_10MINUTE
eSPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE
: intervalli che coprono i 4 giorni precedenti.SPANNER_SYS.QUERY_STATS_TOP_HOUR
eSPANNER_SYS.QUERY_STATS_TOTAL_HOUR
: intervalli che coprono i 30 giorni precedenti.
Esempi di query
Questa sezione include diverse istruzioni SQL di esempio che recuperano le statistiche delle query. Puoi eseguire queste istruzioni SQL utilizzando le librerie client, lo strumento a riga di comando gcloud
o la console Google Cloud.
Elenca le statistiche di base per ogni query in un determinato periodo di tempo
La seguente query restituisce i dati non elaborati per le query principali nel minuto precedente:
SELECT text,
request_tag,
interval_end,
execution_count,
avg_latency_seconds,
avg_rows,
avg_bytes,
avg_rows_scanned,
avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
ORDER BY interval_end DESC;
Elenca le query con il maggiore utilizzo di CPU
La seguente query restituisce le query con il massimo utilizzo di CPU nell'ora precedente:
SELECT text,
request_tag,
execution_count AS count,
avg_latency_seconds AS latency,
avg_cpu_seconds AS cpu,
execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_hour)
ORDER BY total_cpu DESC;
Trovare il numero totale di esecuzioni in un determinato periodo di tempo
La seguente query restituisce il numero totale di query eseguite nell'intervallo completo di 1 minuto più recente:
SELECT interval_end,
execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_minute);
Trovare la latenza media per una query
La query seguente restituisce le informazioni sulla latenza media per una query specifica:
SELECT avg_latency_seconds
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "SELECT x FROM table WHERE x=@foo;";
Trova la latenza del 99° percentile per le query
La seguente query restituisce il 99° percentile del tempo di esecuzione per le query eseguite nei 10 minuti precedenti:
SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution[OFFSET(0)], 99.0)
AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;
Confrontando la latenza media con la latenza del 99° percentile, puoi identificare le possibili query outlier con tempi di esecuzione elevati.
Trova le query che analizzano la maggior parte dei dati
Puoi utilizzare il numero di righe scansionate da una query come misura della quantità di dati analizzati dalla query. La seguente query restituisce il numero di righe scansionate dalle query eseguite nell'ora precedente:
SELECT text,
execution_count,
avg_rows_scanned
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_scanned DESC;
Trova le dichiarazioni che hanno scritto il maggior numero di dati
Puoi utilizzare il numero di righe scritte (o byte scritti) da DML come misurazione della quantità di dati modificata dalla query. La seguente query restituisce il numero di righe scritte dalle istruzioni DML eseguite nell'ora precedente:
SELECT text,
execution_count,
avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_written DESC;
Totale utilizzo CPU per tutte le query
La query seguente restituisce il numero di ore di CPU utilizzate nell'ora precedente:
SELECT (avg_cpu_seconds * execution_count / 60 / 60)
AS total_cpu_hours
FROM spanner_sys.query_stats_total_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_total_hour);
Elenca le query non riuscite in un determinato periodo di tempo
La seguente query restituisce i dati non elaborati, inclusi il numero di esecuzioni e la latenza media delle query non riuscite per le query principali nel minuto precedente:
SELECT text,
request_tag,
interval_end,
execution_count,
all_failed_execution_count,
all_failed_avg_latency_seconds,
avg_latency_seconds,
avg_rows,
avg_bytes,
avg_rows_scanned,
avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;
Trovare il numero totale di errori in un determinato periodo di tempo
La seguente query restituisce il numero totale di query che non è stato possibile eseguire nell'ultimo intervallo completo di 1 minuto.
SELECT interval_end,
all_failed_execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_minute)
ORDER BY interval_end;
Elenca le query che hanno il timeout più elevato
La seguente query restituisce le query con il conteggio di timeout più alto nell'ora precedente.
SELECT text,
execution_count AS count,
timed_out_execution_count AS timeout_count,
avg_latency_seconds AS latency,
avg_cpu_seconds AS cpu,
execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.query_stats_top_hour)
ORDER BY timed_out_execution_count DESC;
Trovare la latenza media delle esecuzioni riuscite e non riuscite per una query
La query seguente restituisce la latenza media combinata di una query specifica e la latenza media per le esecuzioni riuscite e la latenza media per le esecuzioni non riuscite.
SELECT avg_latency_seconds AS combined_avg_latency,
all_failed_avg_latency_seconds AS failed_execution_latency,
( avg_latency_seconds * execution_count -
all_failed_avg_latency_seconds * all_failed_execution_count
) / (
execution_count - all_failed_execution_count ) AS success_execution_latency
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "select x from table where x=@foo;";
Risolvi i problemi di utilizzo elevato della CPU o di elevata latenza delle query con le statistiche sulle query
Le statistiche sulle query sono utili quando devi indagare sull'utilizzo elevato della CPU nel database di Spanner o quando stai semplicemente cercando di comprendere le forme di query con CPU elevata nel tuo database. L'ispezione delle query che utilizzano quantità significative di risorse del database offre agli utenti Spanner un potenziale modo per ridurre i costi operativi ed eventualmente migliorare le latenze generali del sistema.
Puoi utilizzare il codice SQL o la dashboard Approfondimenti sulle query per esaminare le query problematiche nel tuo database. I seguenti argomenti mostrano come esaminare queste query utilizzando il codice SQL.
L'esempio riportato di seguito si concentra sull'utilizzo della CPU, ma puoi seguire passaggi simili per risolvere la latenza di query elevata e trovare le query con le latenza più elevate. Basta selezionare intervalli di tempo e query per latenza invece di utilizzare la CPU.
Seleziona un periodo di tempo da esaminare
Inizia la tua indagine cercando un momento in cui la tua applicazione ha iniziato a notare un elevato utilizzo della CPU. Ad esempio, supponiamo che il problema si sia verificato intorno alle 17:00 del 24 luglio 2020 UTC.
Raccogli le statistiche sulle query per il periodo di tempo selezionato
Dopo aver selezionato un periodo di tempo per avviare la nostra indagine, esamineremo le statistiche raccolte nella tabella QUERY_STATS_TOTAL_10MINUTE
in questo periodo.
I risultati di questa query potrebbero indicare come è cambiata la CPU e altre statistiche delle query nel periodo di tempo in questione.
La seguente query restituisce le statistiche delle query aggregate dalle ore 16:30 alle ore 17:30 UTC incluse. Stiamo utilizzando ROUND
nella nostra query per limitare il numero di posizioni decimali a scopo di visualizzazione.
SELECT interval_end,
execution_count AS count,
ROUND(avg_latency_seconds,2) AS latency,
ROUND(avg_rows,2) AS rows_returned,
ROUND(avg_bytes,2) AS bytes,
ROUND(avg_rows_scanned,2) AS rows_scanned,
ROUND(avg_cpu_seconds,3) AS avg_cpu
FROM spanner_sys.query_stats_total_10minute
WHERE
interval_end >= "2020-07-24T16:30:00Z"
AND interval_end <= "2020-07-24T17:30:00Z"
ORDER BY interval_end;
L'esecuzione della query ha prodotto i seguenti risultati.
intervallo_fine | conteggio | latenza | righe_risolte | byte | righe_scansionate | CPU_media |
---|---|---|---|---|---|---|
24-07-2020T16:30:00Z | 6 | 0,06 | 5,00 | 536,00 | 16,67 | 0,035 |
24-07-2020T16:40:00Z | 55 | 0,02 | 0,22 | 25,29 | 0,22 | 0,004 |
24-07-2020T16:50:00Z | 102 | 0,02 | 0,30 | 33,35 | 0,30 | 0,004 |
2020-07-24T17:00:00Z |
154 |
1.06 |
4.42 |
486.33 |
7792208.12 |
4.633 |
24-07-2020T17:10:00Z | 94 | 0,02 | 1,68 | 106,84 | 1,68 | 0,006 |
24-07-2020T17:20:00Z | 110 | 0,02 | 0,38 | 34,60 | 0,38 | 0,005 |
24-07-2020T17:30:00Z | 47 | 0,02 | 0,23 | 24,96 | 0,23 | 0,004 |
Nella tabella precedente vediamo che la durata media della CPU, la colonna avg_cpu nella tabella dei risultati, è la più alta negli intervalli evidenziati che terminano alle 17:00. Vediamo anche un numero molto più alto di righe scansionate in media. Questo indica che le query più costose sono state eseguite tra le 16:50 e le 17:00. Scegliamo l'intervallo per indagare ulteriormente nel passaggio successivo.
Trovare le query che causano un elevato utilizzo della CPU
Con un intervallo di tempo di indagine selezionato, ora eseguiamo una query sulla tabella QUERY_STATS_TOP_10MINUTE
. I risultati di questa query possono aiutare a indicare le query che causano un elevato utilizzo della CPU.
SELECT text_fingerprint AS fingerprint,
execution_count AS count,
ROUND(avg_latency_seconds,2) AS latency,
ROUND(avg_cpu_seconds,3) AS cpu,
ROUND(execution_count * avg_cpu_seconds,3) AS total_cpu
FROM spanner_sys.query_stats_top_10MINUTE
WHERE
interval_end = "2020-07-24T17:00:00Z"
ORDER BY total_cpu DESC;
L'esecuzione di questa query restituisce i seguenti risultati.
impronta | conteggio | latenza | cpu | CPU_totale |
---|---|---|---|---|
5505124206529314852 |
30 |
3.88 |
17.635 |
529.039 |
1697951036096498470 |
10 |
4.49 |
18.388 |
183.882 |
2295109096748351518 | 1 | 0,33 | 0,048 | 0,048 |
11618299167612903606 | 1 | 0,25 | 0,021 | 0,021 |
10302798842433860499 | 1 | 0,04 | 0,006 | 0,006 |
123771704548746223 | 1 | 0,04 | 0,006 | 0,006 |
4216063638051261350 | 1 | 0,04 | 0,006 | 0,006 |
3654744714919476398 | 1 | 0,04 | 0,006 | 0,006 |
2999453161628434990 | 1 | 0,04 | 0,006 | 0,006 |
823179738756093706 | 1 | 0,02 | 0,005 | 0,0056 |
Le prime 2 query, evidenziate nella tabella dei risultati, sono anomali in termini di CPU e latenza media, nonché numero di esecuzioni e CPU totale. Esaminiamo la prima query elencata in questi risultati.
Confronta le esecuzioni di query nel tempo
Dopo aver ristretto l'ambito dell'indagine, possiamo rivolgere la nostra attenzione alla tabella QUERY_STATS_TOP_MINUTE
. Confrontando le esecuzioni nel tempo per una query specifica, possiamo cercare delle correlazioni tra il numero di righe o byte restituiti oppure il numero di righe scansionate e una CPU o latenza elevata. Una deviazione potrebbe indicare un'uniformità nei dati. Un numero costantemente elevato di righe scansionate può indicare la mancanza di indici appropriati o di un ordine di unione non ottimale.
Esaminiamo la query che mostra il massimo utilizzo medio della CPU e la latenza più alta eseguendo la seguente istruzione che filtra la text_fingerprint di quella query.
SELECT interval_end,
ROUND(avg_latency_seconds,2) AS latency,
avg_rows AS rows_returned,
avg_bytes AS bytes_returned,
avg_rows_scanned AS rows_scanned,
ROUND(avg_cpu_seconds,3) AS cpu,
FROM spanner_sys.query_stats_top_minute
WHERE text_fingerprint = 5505124206529314852
ORDER BY interval_end DESC;
L'esecuzione di questa query restituisce i seguenti risultati.
intervallo_fine | latenza | righe_risolte | byte_ripristinato | righe_scansionate | cpu |
---|---|---|---|---|---|
24-07-2020T17:00:00Z | 4,55 | 21 | 2365 | 30000000 | 19,255 |
24-07-2020T16:00:00Z | 3,62 | 21 | 2365 | 30000000 | 17,255 |
24-07-2020T15:00:00Z | 4,37 | 21 | 2365 | 30000000 | 18,350 |
24-07-2020T14:00:00Z | 4,02 | 21 | 2365 | 30000000 | 17,748 |
24-07-2020T13:00:00Z | 3,12 | 21 | 2365 | 30000000 | 16,380 |
24-07-2020T12:00:00Z | 3,45 | 21 | 2365 | 30000000 | 15,476 |
24-07-2020T11:00:00Z | 4,94 | 21 | 2365 | 30000000 | 22,611 |
24-07-2020T10:00:00Z | 6,48 | 21 | 2365 | 30000000 | 21,265 |
24-07-2020T09:00:00Z | 0,23 | 21 | 2365 | 5 | 0,040 |
24-07-2020T08:00:00Z | 0,04 | 21 | 2365 | 5 | 0,021 |
24-07-2020T07:00:00Z | 0,09 | 21 | 2365 | 5 | 0,030 |
Esaminando i risultati precedenti, vediamo che il numero di righe scansionate, la CPU utilizzata e la latenza sono cambiate in modo significativo intorno alle 9:00. Per capire perché questi numeri sono aumentati così drasticamente, esamineremo il testo della query e verificheremo se eventuali modifiche allo schema potrebbero aver influito sulla query.
Utilizza la seguente query per recuperare il testo della query che stiamo esaminando.
SELECT text,
text_truncated
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852
LIMIT 1;
Viene restituito il seguente risultato.
sms | testo_troncato |
---|---|
select * da ordini dove o_custkey = 36901; | falso |
Esaminando il testo della query che viene restituito, ci rendiamo conto che la query sta filtrando in un campo chiamato o_custkey
. Questa è una colonna non chiave nella tabella orders
. In passato, nella colonna c'era un indice che era stato eliminato intorno alle 09:00. Questo spiega la modifica del costo per questa query. Possiamo aggiungere di nuovo l'indice oppure, se la query viene eseguita raramente, decidere di non avere l'indice e accettare il costo di lettura più elevato.
Finora la nostra indagine si è concentrata su query completate correttamente e abbiamo trovato un motivo per cui il database ha subito un peggioramento delle prestazioni. Nel passaggio successivo, ci concentreremo sulle query non riuscite o annullate e mostreremo come esaminare questi dati per ulteriori informazioni.
Esaminare le query non riuscite
Le query che non vengono completate correttamente consumano ancora risorse prima che scadano, vengano annullate o non vadano a buon fine. Spanner monitora il numero di esecuzioni e le risorse utilizzate dalle query non riuscite insieme a quelle riuscite.
Per verificare se le query non riuscite contribuiscono in modo significativo all'utilizzo del sistema, possiamo innanzitutto verificare quante query non sono andate a buon fine nell'intervallo di tempo interessato.
SELECT interval_end,
all_failed_execution_count AS failed_count,
all_failed_avg_latency_seconds AS latency
FROM spanner_sys.query_stats_total_minute
WHERE
interval_end >= "2020-07-24T16:50:00Z"
AND interval_end <= "2020-07-24T17:00:00Z"
ORDER BY interval_end;
intervallo_fine | numero_non_valido | latenza |
---|---|---|
24-07-2020T16:52:00Z | 1 | 15,211391 |
24-07-2020T16:53:00Z | 3 | 58,312232 |
Analizzando più a fondo il problema, possiamo esaminare le query che con maggiore probabilità non riusciranno a utilizzarle.
SELECT interval_end,
text_fingerprint,
execution_count,
avg_latency_seconds AS avg_latency,
all_failed_execution_count AS failed_count,
all_failed_avg_latency_seconds AS failed_latency,
cancelled_or_disconnected_execution_count AS cancel_count,
timed_out_execution_count AS to_count
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;
intervallo_fine | impronta_testo | numero_esecuzione | numero_non_valido | annulla_conteggio | to_count |
---|---|---|---|---|---|
24-07-2020T16:52:00Z | 5505124206529314852 | 3 | 1 | 1 | 0 |
24-07-2020T16:53:00Z | 1697951036096498470 | 2 | 1 | 1 | 0 |
24-07-2020T16:53:00Z | 5505124206529314852 | 5 | 2 | 1 | 1 |
Come mostra la tabella precedente, la query con l'impronta 5505124206529314852
non è riuscita più volte durante intervalli di tempo diversi. Dato un modello di errori come questo, è interessante confrontare la latenza delle esecuzioni riuscite e non riuscite.
SELECT interval_end,
avg_latency_seconds AS combined_avg_latency,
all_failed_avg_latency_seconds AS failed_execution_latency,
( avg_latency_seconds * execution_count -
all_failed_avg_latency_seconds * all_failed_execution_count
) / (
execution_count - all_failed_execution_count ) AS success_execution_latency
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852;
intervallo_fine | latenza_media_combinata | latenza_non_eseguita | latenza_esecuzione_successa |
---|---|---|---|
24-07-2020T17:00:00Z | 3,880420 | 13,830709 | 2,774832 |
Applica le best practice
Dopo aver identificato una query candidata per l'ottimizzazione, possiamo esaminare il profilo della query e provare a ottimizzare utilizzando le best practice SQL.
Passaggi successivi
Utilizza Query attive meno recenti per determinare le query attive più lunghe.
Scopri di più sull'indagine su un elevato utilizzo della CPU.
Scopri altri strumenti di introspezione.
Scopri altre informazioni relative agli archivi Spanner per ogni database nelle tabelle dello schema di informazioni del database.
Scopri di più sulle best practice SQL per Spanner.