Statistiche sulle query

Cloud Spanner offre tabelle integrate che conservano molte statistiche per le query e le istruzioni DML che hanno utilizzato la maggior parte della CPU, oltre a tutte le query in forma aggregata (incluse le query sul cambia flusso).

Disponibilità

I dati di SPANNER_SYS sono disponibili solo tramite le interfacce SQL, ad esempio:

  • La pagina Query di un database in Google Cloud Console

  • Il comando gcloud spanner databases execute-sql

  • L'API executeQuery

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

Utilizzo CPU raggruppato per query

Le seguenti tabelle monitorano le query con il massimo utilizzo della CPU in un periodo di tempo specifico:

  • SPANNER_SYS.QUERY_STATS_TOP_MINUTE: query a intervalli di 1 minuto
  • SPANNER_SYS.QUERY_STATS_TOP_10MINUTE: query a intervalli di 10 minuti
  • SPANNER_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. Gli intervalli di 1 minuto terminano ogni 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

  • Cloud Spanner raggruppa le statistiche in base al testo della query SQL. Se una query utilizza parametri di ricerca, Cloud Spanner raggruppa tutte le esecuzioni di quella query in una singola riga. Se la query utilizza valori letterali stringa, Cloud Spanner raggruppa le statistiche solo se il testo completo della query è identico; quando un testo è diverso, ogni query viene visualizzata come una riga separata. Per i DML batch, Cloud Spanner normalizza il batch decriptando le istruzioni identiche consecutive prima di generare l'impronta.

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

  • Se Cloud 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 non completate:

    • Conteggio esecuzioni e latenza media in secondi in tutte le query non riuscite.

    • Conteggio esecuzioni delle query in timeout.

    • Conteggio delle esecuzioni 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 è verificata l'esecuzione della query inclusa.
REQUEST_TAG STRING Il tag di richiesta facoltativo per questa operazione di query. Per maggiori informazioni sull'utilizzo dei tag, consulta la pagina Risolvere i problemi relativi ai tag di richiesta.
TEXT STRING Testo della query SQL, troncato a circa 64 kB.

Le statistiche di più query con la stessa stringa tag sono raggruppate in una singola riga con la stringa REQUEST_TAG corrispondente. In questo campo viene visualizzato solo il testo di una di queste query, troncato a circa 64 kB. Per i DML batch, l'insieme di istruzioni SQL è uniforme in una singola riga, concatenata con un delimitatore e virgola. I testi SQL identici consecutivi vengono deduplicati prima del troncamento.
TEXT_TRUNCATED BOOL Indica se il testo della query è stato troncato.
TEXT_FINGERPRINT INT64 L'hash del valore REQUEST_TAG, se presente; altrimenti, l'hash del valore TEXT.
EXECUTION_COUNT INT64 Numero di volte in cui Cloud Spanner ha visto 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 l'insieme 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, escluso l'overhead di codifica di 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 utilizzati da Cloud Spanner in tutte le operazioni per eseguire la 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 l'insieme di risultati e 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 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 dichiarazioni aggregate in questa voce. Per le query normali e i DML, questo sarà uguale al conteggio di esecuzione. Per i DML batch, Cloud Spanner acquisisce il numero di istruzioni nel batch.

EXECUTION_COUNT e AVG_LATENCY_SECONDS per le query non riuscite includono le query non riuscite a causa di una sintassi errata o un errore temporaneo, ma riuscite al nuovo tentativo.

Statistiche aggregate

Sono inoltre disponibili tabelle che monitorano i dati aggregati per tutte le query per le quali Cloud Spanner ha acquisito statistiche in un periodo di tempo specifico:

  • SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: query a intervalli di 1 minuto
  • SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: query a intervalli di 10 minuti
  • SPANNER_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. Gli intervalli di 1 minuto terminano ogni 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 nel database durante l'intervallo specificato, aggregate insieme. C'è una sola riga per intervallo di tempo che include le query completate, quelle non riuscite e quelle annullate dall'utente.

  • Le statistiche acquisite nelle tabelle TOTAL potrebbero includere query che Cloud Spanner non ha acquisito nelle tabelle TOP.

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

    • Conteggio esecuzione query
    • Errori delle query
    • Latenze di query
    • Conteggio delle righe restituite
    • Conteggio delle righe scansionate
    • Conteggio dei byte restituiti
    • Tempo di CPU query

    Per ulteriori informazioni, consulta le metriche di Cloud Spanner.

Schema tabella

Nome colonna Tipo Descrizione
INTERVAL_END TIMESTAMP Fine dell'intervallo di tempo in cui si è verificata l'esecuzione della query inclusa.
EXECUTION_COUNT INT64 Numero di volte in cui Cloud Spanner ha visto 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 l'insieme 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, escluso l'overhead di codifica di 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 utilizzati da Cloud Spanner in tutte le operazioni per eseguire la 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 l'insieme di risultati e 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 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.

Conservazione dei dati

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

  • SPANNER_SYS.QUERY_STATS_TOP_MINUTE e SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: intervalli che riguardano le 6 ore precedenti.

  • SPANNER_SYS.QUERY_STATS_TOP_10MINUTE e SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: intervalli che coprono i 4 giorni precedenti.

  • SPANNER_SYS.QUERY_STATS_TOP_HOUR e SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: intervalli che coprono i 30 giorni precedenti.

Esempi di query

Questa sezione include diversi esempi di istruzioni SQL che recuperano le statistiche delle query. Per eseguire queste istruzioni SQL puoi utilizzare le librerie client, lo strumento a riga di comando gcloud o Google Cloud Console.

Indicare 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;

Elenco delle query con il massimo utilizzo della CPU

La query seguente restituisce le query con il massimo utilizzo della 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 più recente di un minuto completato:

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 le query che analizzano la maggior parte dei dati

Puoi utilizzare il numero di righe scansionate da una query per misurare la quantità di dati scansionati dalla query. La seguente query restituisce il numero di righe analizzate da 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 la maggior parte dei dati

Puoi utilizzare il numero di righe scritte (o byte scritti) da DML come misura della quantità di dati modificata dalla query. La query seguente 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 dell'utilizzo 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);

Elenco delle query non riuscite in un determinato periodo di tempo

La seguente query restituisce i dati non elaborati, inclusi il numero di esecuzione 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 query seguente restituisce il numero totale di query che non è stato possibile eseguire 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;

Elencare le query che scadono più spesso

La seguente query restituisce le query con il conteggio di timeout più elevato 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, 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;";

Risoluzione dei problemi di utilizzo elevato della CPU o di latenza elevata delle query con le statistiche delle query

Le statistiche sulle query sono utili quando devi analizzare l'utilizzo elevato della CPU dal database Cloud Spanner o quando stai semplicemente cercando di comprenderne le forme pesanti. L'ispezione delle query che utilizzano quantità significative di risorse del database offre agli utenti di Cloud Spanner un modo potenziale per ridurre i costi operativi ed eventualmente migliorare le latenze di sistema generali. Utilizzando la procedura seguente, ti mostreremo come utilizzare le statistiche sulle query per analizzare l'utilizzo elevato della CPU nel tuo database.

L'esempio riportato di seguito si concentra sull'utilizzo della CPU, ma puoi seguire passaggi simili per risolvere i problemi di latenza elevata delle query e trovare le query con le latenze più elevate. È sufficiente selezionare intervalli di tempo e query per latenza anziché utilizzare la CPU.

Selezione di un periodo di tempo da esaminare

Avvia l'indagine cercando il momento in cui la tua applicazione ha iniziato a registrare un elevato utilizzo della CPU. Ad esempio, supponiamo che il problema abbia iniziato a verificarsi attorno alle 17:00 del 24 luglio 2020 UTC.

Raccolta di statistiche delle query per il periodo di tempo selezionato

Dopo aver selezionato un periodo di tempo per avviare la nostra indagine, daremo un'occhiata alle statistiche raccolte nella tabella QUERY_STATS_TOTAL_10MINUTE intorno a quel periodo. I risultati di questa query potrebbero indicare in che modo la CPU e altre statistiche della query sono cambiate in un periodo di tempo specifico.

La query seguente restituisce le statistiche aggregate delle query dalle 16:30 alle 17:30 UTC incluse. Stiamo utilizzando ROUND nella nostra query per limitare il numero di cifre 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 usando la riga byte righe_scansionate media_cpu
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 il tempo medio di CPU, la colonna avg_cpu nella tabella dei risultati, è la più alta negli intervalli evidenziati che terminano alle ore 17:00. Inoltre, notiamo in media un numero molto più elevato di righe scansionate. a indicare che le query più costose sono state eseguite tra le 16:50 e le 17:00. Scegliamo l'intervallo per esaminare ulteriormente il problema nel passaggio successivo.

Individuare 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 aiutarti a indicare quali query 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 produce 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 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. Analizziamo la prima query elencata in questi risultati.

Confronto delle query eseguite nel tempo

Dopo aver limitato l'ambito dell'indagine, possiamo concentrare la nostra attenzione sulla tabella QUERY_STATS_TOP_MINUTE. Confrontando le esecuzioni nel tempo di una determinata query, possiamo cercare le correlazioni tra il numero di righe o byte restituiti o il numero di righe analizzate e la CPU o la latenza elevata. Una deviazione potrebbe indicare la non uniformità dei dati. Un numero di righe costantemente elevato può indicare la mancanza di indici appropriati o di ordini di unione non ottimali.

Esaminiamo la query che mostra il massimo utilizzo medio della CPU e la latenza più elevata eseguendo la seguente istruzione che filtra l'impronta di testo 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.

intervallo_fine latenza usando la riga byte_returned 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 analizzate, CPU utilizzate e latenza è cambiato in modo significativo intorno alle 9:00. Per capire perché questi numeri sono aumentati in modo così drastico, 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 per la query che stiamo esaminando.

SELECT text,
       text_truncated
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852
LIMIT 1;

Restituisce il seguente risultato.

sms testo_troncato
seleziona * da ordini dove o_custkey = 36901; falso

Esaminando il testo della query che viene restituito, abbiamo capito che la query sta filtrando in un campo chiamato o_custkey. Questa è una colonna non chiave nella tabella orders. In quel momento, nella colonna c'era un indice che è stato rilasciato 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.

La nostra indagine è stata incentrata sulle query completate correttamente e abbiamo trovato un motivo per cui il database stava registrando un peggioramento delle prestazioni. Nel prossimo passaggio ci concentreremo sulle query non riuscite o annullate e mostreremo come esaminare questi dati per ulteriori informazioni.

Analisi delle query non riuscite

Le query che non vengono completate correttamente, consumano ancora le risorse prima che scadano, vengano annullate o non vadano a buon fine. Cloud Spanner traccia il numero di esecuzione 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, per prima cosa possiamo verificare quante query non sono 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;
intervallo_fine failed_count latenza
24-07-2020T16:52:00Z 1 15,211391
24-07-2020T16:53:00Z 3 58,312232

Esaminando ulteriormente la situazione, possiamo cercare query con maggiori probabilità di non utilizzare la query seguente.

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 text_fingerprint esecuzione_numero failed_count cancel_count 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 pattern 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 combinazione_media_latenza non è possibile_execution_latency Success_execution_latency
24-07-2020T17:00:00Z 3,880420 13,830709 2,774832

Applicazione delle best practice

Dopo aver identificato una query candidato per l'ottimizzazione, possiamo esaminare il profilo di query e provare a eseguire l'ottimizzazione utilizzando le best practice per SQL.

Passaggi successivi