Spanner fornisce tabelle integrate che conservano molte statistiche per le query e le istruzioni DML che hanno utilizzato più CPU e per tutte le query in forma aggregata (incluse le query di flusso di modifiche).
Disponibilità
I dati di SPANNER_SYS
sono disponibili solo tramite le interfacce SQL, ad esempio:
La pagina di Spanner Studio di un database nella console Google Cloud
Il comando
gcloud spanner databases execute-sql
Dashboard di Approfondimenti sulle query
API
executeQuery
Altri metodi di lettura singoli forniti da Spanner non supportano SPANNER_SYS
.
Utilizzo CPU raggruppato per query
Le seguenti tabelle tengono traccia delle query con il maggiore utilizzo di CPU durante un periodo di tempo specifico:
SPANNER_SYS.QUERY_STATS_TOP_MINUTE
: query a intervalli di 1 minutoSPANNER_SYS.QUERY_STATS_TOP_10MINUTE
: query a intervalli di 10 minutiSPANNER_SYS.QUERY_STATS_TOP_HOUR
: query a intervalli di 1 ora
Queste tabelle hanno le seguenti proprietà:
Ogni tabella contiene dati per intervalli di tempo non sovrapposti della lunghezza specificata dal nome della tabella.
Gli intervalli sono basati sugli orari dell'orologio. 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 ogni 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 query, Spanner raggruppa tutte le esecuzioni della query in una singola riga. Se la query utilizza valori letterali stringa, Spanner raggruppa le statistiche solo se il testo completo della query è identico; quando il testo è diverso, ogni query viene visualizzata come una riga separata. Per DML in modalità 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 della richiesta. Altrimenti, è l'hash del valore
TEXT
.Ogni riga contiene le statistiche per 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 assegna la priorità alle query con il maggiore utilizzo di CPU durante l'intervallo specificato.
Le query monitorate includono quelle che sono state completate, non sono riuscite o sono state annullate dall'utente.
Un sottoinsieme di statistiche è specifico per le query eseguite, ma non completate:
Conteggio delle esecuzioni e latenza media in secondi per tutte le query non riuscite.
Conteggio delle esecuzioni per le query scadute.
Conteggio delle esecuzioni per le query annullate dall'utente o non riuscite a causa di problemi di connettività di rete.
Tutte le colonne delle tabelle sono nulli.
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 ulteriori informazioni sull'uso dei tag, consulta Risoluzione dei problemi relativi ai tag di richiesta. | |
QUERY_TYPE |
STRING |
Indica se una query è PARTITIONED_QUERY o
QUERY . Un PARTITIONED_QUERY
è una query con un partitionToken ottenuto dall'API PartitionQuery. Tutte le altre query e le istruzioni DML sono indicate dal tipo di query QUERY .
Le statistiche delle query per
DML partizionato non sono
supportate.
|
|
TEXT |
STRING |
Testo della query SQL troncato a circa 64 kB.
Le statistiche relative a più query con la stessa stringa tag sono raggruppate in una singola riga con il REQUEST_TAG corrispondente alla stringa tag. In questo campo viene visualizzato solo il testo di una di queste query, troncato a circa 64 kB.
Per DML in batch, il set di istruzioni SQL viene suddiviso in una singola
riga, concatenata tramite un delimitatore di punto e virgola. I testi SQL identici consecutivi vengono deduplicati prima del troncamento.
|
|
TEXT_TRUNCATED |
BOOL |
Indica se il testo della query è stato troncato o meno. | |
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 Spanner ha visto la query durante l'intervallo. | |
AVG_LATENCY_SECONDS |
FLOAT64 |
Tempo medio, in secondi, per ogni esecuzione di query all'interno del database. Questa media esclude il tempo di codifica e di trasmissione per il set di risultati, nonché l'overhead. | |
AVG_ROWS |
FLOAT64 |
Numero medio di righe restituite dalla query. | |
AVG_BYTES |
FLOAT64 |
Numero medio di byte di dati restituiti dalla query, escluso l'overhead della codifica di trasmissione. | |
AVG_ROWS_SCANNED |
FLOAT64 |
Numero medio di righe analizzate dalla query, esclusi i valori eliminati. | |
AVG_CPU_SECONDS |
FLOAT64 |
Numero medio di secondi di tempo di CPU impiegato da Spanner in tutte le operazioni per eseguire la query. | |
ALL_FAILED_EXECUTION_COUNT |
INT64 |
Numero di volte in cui la query non è riuscita durante l'intervallo. | |
ALL_FAILED_AVG_LATENCY_SECONDS |
FLOAT64 |
Tempo medio, in secondi, per ogni esecuzione di query non riuscita all'interno del database. Questa media esclude il tempo di codifica e trasmissione per il set di risultati, nonché l'overhead. | |
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT |
INT64 |
Numero di volte in cui la query è stata annullata dall'utente o non è riuscita a causa di un'interruzione della connessione di rete durante l'intervallo. | |
TIMED_OUT_EXECUTION_COUNT |
INT64 |
Numero di volte in cui la query è scaduta 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 degli estratti conto aggregati in questa voce. Per query normali e DML, questo valore corrisponde al numero di esecuzioni. Per 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 i conflitti di blocco spostando la 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 dalla distribuzione,
utilizza la funzione Per saperne di più, consulta Percentile e metriche con valori di distribuzione. |
|
AVG_MEMORY_PEAK_USAGE_BYTES |
FLOAT64 |
Durante l'esecuzione di una query distribuita, il picco di utilizzo medio di memoria (in byte). Utilizza questa statistica per identificare quali query o dimensioni dei dati delle tabelle hanno maggiori probabilità di riscontrare limiti di memoria. |
|
AVG_MEMORY_USAGE_PERCENTAGE |
FLOAT64 |
Durante l'esecuzione di una query distribuita, l'utilizzo medio della memoria richiesto (come percentuale del limite di memoria consentito per questa query). Questa statistica tiene traccia solo della memoria necessaria per l'esecuzione
della query. Alcuni operatori utilizzano memoria di buffering aggiuntiva per migliorare le prestazioni. La memoria di buffering aggiuntiva utilizzata è visibile nel piano di query, ma non viene utilizzata per calcolare Utilizza questa statistica per identificare le query che stanno per raggiungere il limite di utilizzo della memoria e che rischiano di non funzionare se le dimensioni dei dati aumentano. Per ridurre il rischio che la query non vada a buon fine, consulta le best practice SQL per ottimizzare queste query o suddividi la query in parti con meno dati. |
|
AVG_QUERY_PLAN_CREATION_TIME_SECS |
FLOAT64 |
Il tempo medio di CPU in secondi impiegato per la compilazione delle query, inclusa la creazione del runtime delle query. Se il valore di questa colonna è elevato, utilizza le query con parametri. |
|
AVG_FILESYSTEM_DELAY_SECS |
FLOAT64 |
Il tempo medio impiegato dalla query per leggere dal file system o per essere bloccata su input/output (I/O). Utilizza questa statistica per identificare la potenziale latenza elevata causata dall'I/O del file system. Per mitigare l'impatto, aggiungi un indice o una clausola |
|
AVG_REMOTE_SERVER_CALLS |
FLOAT64 |
Il numero medio di chiamate al server remoto (RPC) completate dalla query. Utilizza questa statistica per identificare se query diverse che analizzano lo stesso numero di righe hanno un numero molto diverso di RPC. La query con un valore RPC più elevato potrebbe trarre vantaggio dall'aggiunta di un indice o di una clausola |
|
AVG_ROWS_SPOOLED |
FLOAT64 |
Il numero medio di righe scritte su un disco temporaneo (non in memoria) dall'istruzione della query. Utilizza questa statistica per identificare le query potenzialmente ad alta latenza
che richiedono molte risorse per la memoria e non possono essere eseguite in memoria. Per ridurre l'impatto, modifica l'ordine di |
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 il tentativo è stato eseguito correttamente.
Statistiche aggregate
Esistono anche tabelle che tengono traccia dei dati aggregati per tutte le query per le quali Spanner ha acquisito le statistiche in un periodo di tempo specifico:
SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE
: query a intervalli di 1 minutoSPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE
: query a intervalli di 10 minutiSPANNER_SYS.QUERY_STATS_TOTAL_HOUR
: query a intervalli di 1 ora
Queste tabelle hanno le seguenti proprietà:
Ogni tabella contiene dati per intervalli di tempo non sovrapposti della lunghezza specificata dal nome della tabella.
Gli intervalli sono basati sugli orari dell'orologio. 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 ogni 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. È presente una sola riga per intervallo di tempo e include le query completate, le query non riuscite e le query 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 esecuzioni query
- Errori di query
- Latenze di query
- Conteggio delle righe restituito
- Conteggio righe scansionate
- Conteggio dei byte restituiti
- Tempo di CPU per la query
Per ulteriori informazioni, consulta 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 Spanner ha visto la query durante l'intervallo di tempo in questione. |
AVG_LATENCY_SECONDS |
FLOAT64 |
Tempo medio, in secondi, per ogni esecuzione di query all'interno del database. Questa media esclude il tempo di codifica e di trasmissione per il set di risultati, nonché l'overhead. |
AVG_ROWS |
FLOAT64 |
Numero medio di righe restituite dalla query. |
AVG_BYTES |
FLOAT64 |
Numero medio di byte di dati restituiti dalla query, escluso l'overhead della codifica di trasmissione. |
AVG_ROWS_SCANNED |
FLOAT64 |
Numero medio di righe analizzate dalla query, esclusi i valori eliminati. |
AVG_CPU_SECONDS |
FLOAT64 |
Numero medio di secondi di tempo di CPU impiegato da Spanner in tutte le operazioni per eseguire la query. |
ALL_FAILED_EXECUTION_COUNT |
INT64 |
Numero di volte in cui la query non è riuscita durante l'intervallo. |
ALL_FAILED_AVG_LATENCY_SECONDS |
FLOAT64 |
Tempo medio, in secondi, per ogni esecuzione di query non riuscita all'interno del database. Questa media esclude il tempo di codifica e trasmissione per il set di risultati, nonché l'overhead. |
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT |
INT64 |
Numero di volte in cui la query è stata annullata dall'utente o non è riuscita a causa di un'interruzione della connessione di rete durante l'intervallo. |
TIMED_OUT_EXECUTION_COUNT |
INT64 |
Numero di volte in cui la query è scaduta 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 è possibile evitare i conflitti di blocco spostando alcune query alle transazioni di sola lettura. |
LATENCY_DISTRIBUTION |
ARRAY<STRUCT> |
Un istogramma del tempo di esecuzione tra le query. I valori vengono misurati in secondi.
Specifica l'array come segue:
Per calcolare la latenza percentile dalla distribuzione,
utilizza la funzione Per saperne di più, consulta Percentile e metriche con valori di distribuzione. |
Conservazione dei dati
Spanner conserva i dati di ogni tabella come minimo 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, Google Cloud CLI 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 del 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 l'utilizzo maggiore 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 conteggio totale delle 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 seguente query 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;";
Trovare la latenza al 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;
Confrontare la latenza media con la latenza del 99° percentile consente di identificare possibili query outlier con tempi di esecuzione elevati.
Trova le query che analizzano la maggior parte dei dati
Puoi utilizzare il numero di righe analizzate 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;
Trovare le istruzioni che hanno scritto il maggior numero di dati
Puoi utilizzare il numero di righe scritte (o byte scritti) da DML come misura della quantità di dati modificati 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;
Utilizzo totale della CPU in tutte le query
La seguente query restituisce il numero di ore 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 del 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 sono state eseguite nell'intervallo completo di 1 minuto più recente.
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 raggiunto il timeout più spesso
La seguente query restituisce le query con il numero 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 seguente query restituisce la latenza media combinata, la latenza media per le esecuzioni riuscite e la latenza media per le esecuzioni non riuscite per una query specifica.
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 latenza elevata delle query con le statistiche delle query
Le statistiche sulle query sono utili quando devi analizzare l'utilizzo elevato della CPU nel tuo database Spanner o quando stai solo cercando di comprendere le forme di query che usano molta CPU nel tuo database. L'ispezione delle query che utilizzano quantità significative di risorse di database offre agli utenti di Spanner un modo potenziale per ridurre i costi operativi ed eventualmente migliorare le latenze generali del sistema.
Puoi utilizzare il codice SQL o la dashboard Approfondimenti query per analizzare le query problematiche nel tuo database. I seguenti argomenti mostrano come esaminare queste query utilizzando il codice SQL.
Sebbene l'esempio seguente sia incentrato sull'utilizzo della CPU, è possibile seguire passaggi simili per risolvere i problemi di latenza delle query elevata e trovare le query con le latenze più elevate. È sufficiente selezionare intervalli di tempo e query in base alla latenza anziché all'utilizzo della CPU.
Seleziona un periodo di tempo per l'indagine
Inizia la tua indagine cercando un momento in cui l'applicazione ha iniziato a registrare un utilizzo elevato della CPU. Ad esempio, se il problema ha iniziato a verificarsi all'incirca 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 l'inizio dell'indagine, esamineremo le statistiche raccolte nella tabella QUERY_STATS_TOTAL_10MINUTE
all'incirca in quel periodo.
I risultati di questa query potrebbero indicare come sono cambiate la CPU e altre statistiche delle query nel periodo di tempo in questione.
La seguente query restituisce le statistiche aggregate sulle query dalle ore 16:30 alle ore 17:30 UTC incluse. Usiamo ROUND
nella nostra query per
limitare il numero di cifre decimali ai fini 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.
interval_end | count | latenza | rows_returned | byte | rows_scanned | avg_cpu |
---|---|---|---|---|---|---|
2020-07-24T16:30:00Z | 6 | 0,06 | 5,00 | 536,00 | 16,67 | 0,035 |
2020-07-24T16:40:00Z | 55 | 0,02 | 0,22 | 25,29 | 0,22 | 0,004 |
2020-07-24T16: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 |
2020-07-24T17:10:00Z | 94 | 0,02 | 1,68 | 106,84 | 1,68 | 0,006 |
2020-07-24T17:20:00Z | 110 | 0,02 | 0,38 | 34,60 | 0,38 | 0,005 |
2020-07-24T17:30:00Z | 47 | 0,02 | 0,23 | 24,96 | 0,23 | 0,004 |
Nella tabella precedente vediamo che il tempo di CPU medio, ovvero la colonna avg_cpu nella tabella dei risultati, è più alto negli intervalli evidenziati che terminano alle 17:00. Notiamo anche un numero molto più elevato di righe scansionate, in media. Ciò indica che le query più costose sono state eseguite tra le 16:50 e le 17:00. Scegli l'intervallo per analizzare più a fondo il passaggio successivo.
Trova le query che causano un utilizzo elevato della CPU
Ora che è selezionato un intervallo di tempo per l'indagine, eseguiamo query sulla tabella QUERY_STATS_TOP_10MINUTE
. I risultati di questa query possono
indicare quali query causano un utilizzo elevato 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 | count | latenza | cpu | total_cpu |
---|---|---|---|---|
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 due query principali, evidenziate nella tabella dei risultati, sono outlier in termini di CPU e latenza medie, nonché di numero di esecuzioni e CPU totale. Esamina la prima query elencata in questi risultati.
Confronta le esecuzioni delle query nel tempo
Dopo aver ristretto l'indagine, possiamo rivolgere la nostra attenzione alla tabella QUERY_STATS_TOP_MINUTE
. Confrontando le esecuzioni eseguite nel tempo per una determinata query, possiamo cercare correlazioni tra il numero di righe o byte restituiti o il numero di righe analizzate e CPU o latenza elevate. Una deviazione potrebbe indicare la non uniformità dei dati. Un numero costantemente elevato di righe scansionate può indicare la mancanza di indici appropriati o un ordine dei join non ottimale.
Esamina la query che mostra l'utilizzo medio della CPU più elevato e la latenza più elevata eseguendo la seguente istruzione, che filtra in base a text_fingerprint della 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.
interval_end | latenza | rows_returned | bytes_returned | rows_scanned | cpu |
---|---|---|---|---|---|
2020-07-24T17:00:00Z | 4,55 | 21 | 2365 | 30000000 | 19,255 |
2020-07-24T16:00:00Z | 3,62 | 21 | 2365 | 30000000 | 17,255 |
2020-07-24T15:00:00Z | 4,37 | 21 | 2365 | 30000000 | 18,350 |
2020-07-24T14:00:00Z | 4,02 | 21 | 2365 | 30000000 | 17,748 |
2020-07-24T13:00:00Z | 3,12 | 21 | 2365 | 30000000 | 16,380 |
2020-07-24T12:00:00Z | 3,45 | 21 | 2365 | 30000000 | 15,476 |
2020-07-24T11:00:00Z | 4,94 | 21 | 2365 | 30000000 | 22,611 |
2020-07-24T10:00:00Z | 6,48 | 21 | 2365 | 30000000 | 21,265 |
2020-07-24T09:00:00Z | 0,23 | 21 | 2365 | 5 | 0,040 |
2020-07-24T08:00:00Z | 0,04 | 21 | 2365 | 5 | 0,021 |
2020-07-24T07:00:00Z | 0,09 | 21 | 2365 | 5 | 0,030 |
Esaminando i risultati precedenti, notiamo che il numero di righe analizzate, la CPU utilizzata e la latenza sono cambiati in modo significativo intorno alle 9:00. Per capire perché questi numeri sono aumentati così enormemente, esamineremo il testo della query e vediamo se sono state apportate modifiche allo schema che 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.
testo | text_truncated |
---|---|
selezionare * dagli ordini in cui o_custkey = 36901; | false |
Esaminando il testo della query restituito, ci rendiamo conto che la query filtra in un campo denominato o_custkey
. Questa è una colonna non chiave nella tabella orders
. In precedenza, in quella colonna c'era un indice che era diminuito intorno alle 9:00. Ciò spiega la variazione del costo per questa query. Possiamo aggiungere di nuovo l'indice o, 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 sulle query completate con successo e abbiamo trovato un motivo per cui le prestazioni del database stavano peggiorando. Nel passaggio successivo, ci concentreremo sulle query non riuscite o annullate e mostreremo come esaminare questi dati per ottenere ulteriori insight.
Esamina le query non riuscite
Le query che non vengono completate correttamente consumano comunque risorse prima che scadano, vengano annullate o comunque abbiano esito negativo. 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 prima controllare quante query non riuscite nell'intervallo di tempo di interesse.
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;
interval_end | failed_count | latenza |
---|---|---|
2020-07-24T16:52:00Z | 1 | 15,211391 |
2020-07-24T16:53:00Z | 3 | 58,312232 |
Approfondendo ulteriormente l'analisi, possiamo cercare le query che hanno maggiori probabilità di non riuscire utilizzando la seguente query.
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;
interval_end | text_fingerprint | execution_count | failed_count | cancel_count | to_count |
---|---|---|---|---|---|
2020-07-24T16:52:00Z | 5505124206529314852 | 3 | 1 | 1 | 0 |
2020-07-24T16:53:00Z | 1697951036096498470 | 2 | 1 | 1 | 0 |
2020-07-24T16:53:00Z | 5505124206529314852 | 5 | 2 | 1 | 1 |
Come mostra la tabella precedente, la query con impronta 5505124206529314852
ha avuto esito negativo più volte in diversi intervalli di tempo. Dato uno schema 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;
interval_end | combined_avg_latency | failed_execution_latency | success_execution_latency |
---|---|---|---|
2020-07-24T17:00:00Z | 3,880420 | 13,830709 | 2,774832 |
Applica le best practice
Una volta identificata una query candidata per l'ottimizzazione, possiamo passare a esaminare il profilo query e provare a ottimizzarlo utilizzando le best practice SQL.
Passaggi successivi
Usa Query attive meno recenti per determinare le query attive più lunghe.
Scopri di più sull'analisi di un elevato utilizzo della CPU.
Scopri di più sugli altri strumenti di introspezione.
Scopri di più sulle altre informazioni che Spanner archivia per ogni database nelle tabelle dello schema di informazioni del database.
Scopri di più sulle best practice SQL per Spanner.