Risolvere gli errori di superamento della scadenza di Spanner

Questa pagina fornisce una panoramica degli errori di superamento della scadenza di Spanner: cosa sono, perché si verificano e come risolverli.

Quando accedi alle API Spanner, le richieste potrebbero non riuscire a causa DEADLINE_EXCEEDED errore. Questo errore indica che una risposta non è stata ricevute entro il periodo di timeout configurato.

L'errore di superamento della scadenza può verificarsi per diversi motivi, ad esempio: istanze Spanner con sovraccarico, schemi non ottimizzati o query. In questa pagina vengono descritti gli scenari comuni in cui una scadenza ha superato l'errore Google Cloud e fornisce una guida su come analizzare e risolvere questi problemi.

La scadenza e la filosofia dei nuovi tentativi di Spanner

La filosofia delle scadenze e dei nuovi tentativi di Spanner è diversa da molte altre sistemi operativi. In Spanner, devi specificare una scadenza di timeout come il periodo di tempo massimo in cui una risposta è utile. Impostare una funzionalità una scadenza breve solo per riprovare immediatamente la stessa operazione non è poiché ciò porta a situazioni in cui le operazioni non vengono mai completate. Nella in questo contesto, si sconsigliano le seguenti strategie e operazioni: loro sono controproduttivi e annullano il nuovo tentativo interno di Spanner comportamento:

  • Impostare una scadenza troppo breve. Ciò significa che l'operazione resiliente agli aumenti occasionali della latenza di coda e non può essere completato prima si verifica un timeout. Imposta invece una scadenza che corrisponda al tempo massimo in cui una risposta è utile.

  • Impostare una scadenza troppo lunga e annullare l'operazione prima del giorno la scadenza del periodo di conservazione. Questo porta a nuovi tentativi e sprechi di lavoro a ogni tentativo. Nella aggregati, questo può creare un carico aggiuntivo significativo sulla tua istanza.

Che cos'è l'errore di superamento della scadenza?

Quando utilizzi una delle librerie client di Spanner, lo strato gRPC sottostante si occupa di comunicazione, marshalling, annullamento del marshalling, e l'applicazione delle scadenze. Le scadenze consentono alla tua richiesta di specificare per quanto tempo si è disposti ad attendere il completamento di una richiesta prima che venga risolta con l'errore di scadenza superata.

La guida alla configurazione del timeout illustra come specificare le scadenze (o timeout) in ciascuno degli strumenti Spanner supportati librerie client. Le librerie client di Spanner utilizzano il timeout predefinito e riprova, definite nei file di configurazione seguenti:

Per scoprire di più sulle scadenze di gRPC, consulta gRPC e scadenze.

Come analizzare e risolvere gli errori comuni di superamento della scadenza

Potresti riscontrare DEADLINE_EXCEEDED di errori per i seguenti tipi di problemi:

Problemi relativi all'API di accesso ai dati

Un'istanza Spanner deve essere configurata correttamente per carichi di lavoro specifici per evitare problemi relativi all'API Data Access. Le seguenti sezioni descrivere come analizzare e risolvere i diversi problemi dell'API di accesso ai dati.

Controllare il carico della CPU dell'istanza Spanner

La latenza delle richieste può aumentare notevolmente quando l'utilizzo della CPU attraversa soglia di stato integro consigliata. Puoi controllare l'utilizzo della CPU da parte di Spanner nella console di monitoraggio disponibili nella console Google Cloud. Puoi anche creare avvisi in base all'utilizzo della CPU dell'istanza.

Risoluzione

Per conoscere la procedura per ridurre l'utilizzo della CPU da parte dell'istanza, consulta Ridurre l'utilizzo della CPU.

Controlla la suddivisione della latenza end-to-end della richiesta

Quando una richiesta si sposta dal client ai server Spanner e viceversa, occorre effettuare diversi hop di rete: dalla libreria client Google Front End (GFE); dal GFE al frontend dell'API Spanner; e infine dal frontend dell'API Spanner il database Spanner. Se ci sono problemi di rete in uno di questi fasi, potresti notare errori relativi al superamento della scadenza.

È possibile acquisire la latenza in ogni fase. Per saperne di più, vedi Punti di latenza in una richiesta Spanner. Per trovare dove si verifica la latenza in Spanner, consulta identificare dove si verifica la latenza in Spanner.

Risoluzione

Una volta ottenuta l'analisi della latenza, puoi utilizzare le metriche per diagnosticare la latenza, comprendere perché sta succedendo e trovare soluzioni.

Problemi relativi all'API di dati

Alcuni pattern di utilizzo non ottimali dell'API Data di Spanner potrebbero causa errori di superamento della scadenza. Questa sezione fornisce linee guida su come per verificare la presenza di modelli di utilizzo non ottimali.

Cerca query costose

Tentativo di eseguire query costose che non vengono eseguite entro il timeout configurato di scadenza nelle librerie client potrebbe comportare un errore di superamento della scadenza. Alcune esempi di query costose includono, a titolo esemplificativo, scansioni complete di un una tabella grande, i cross-join su più tabelle di grandi dimensioni oppure l'esecuzione di una query su una colonna non chiave (anche una scansione completa della tabella).

Puoi esaminare query costose utilizzando la tabella delle statistiche sulle query e la tabella delle statistiche sulle transazioni. Queste tabelle mostrano informazioni su transazioni e query a esecuzione lenta, come come il numero medio di righe lette, la media dei byte letti, il numero medio di righe scansionate e altro ancora. Inoltre, puoi generare piani di esecuzione delle query per controllare ulteriormente l'esecuzione delle query.

Risoluzione

Per ottimizzare le query, utilizza la guida alle best practice per le query SQL. Puoi anche utilizzare i dati ottenuti tramite le tabelle delle statistiche menzionate in precedenza ed eseguire i piani per ottimizzare le query e apportare modifiche allo schema ai tuoi database. Queste best practice possono aiutare a ridurre i tempi di esecuzione le dichiarazioni, contribuendo potenzialmente a eliminare gli errori di superamento della scadenza.

Verificare la contesa del blocco

Le transazioni Spanner devono acquisire blocchi di eseguire il commit. Le applicazioni eseguite con una velocità effettiva elevata possono causare competere per le stesse risorse, causando un aumento dell'attesa per ottenere i blocchi influire sulle prestazioni complessive. Di conseguenza, le scadenze per qualsiasi di lettura o scrittura.

Puoi trovare la causa principale delle transazioni di lettura-scrittura ad alta latenza Utilizza la tabella delle statistiche sui blocchi e dai un'occhiata al seguente post del blog. Nella tabella delle statistiche di blocco puoi trovare le chiavi di riga con il numero tempi di attesa per il blocco.

Questa guida alla risoluzione dei problemi relativi ai conflitti di blocco spiega come trovare le transazioni che accedono alle colonne interessate sono in conflitto con la serratura. Puoi anche scoprire quali transazioni sono coinvolte in una conflitto di blocchi utilizzando la guida alla risoluzione dei problemi con i tag transazione.

Risoluzione

Applica queste best practice per ridurre i conflitti di blocco. Inoltre, utilizza le transazioni di sola lettura. per i casi d'uso di letture semplici, per evitare conflitti di blocco con le scritture. Utilizzo Le transazioni di lettura/scrittura devono essere riservate alle operazioni di scrittura o a flussi di lavoro misti di lettura e scrittura. Seguire questi passaggi dovrebbe migliorare la latenza complessiva della transazione di esecuzione e ridurre gli errori di superamento della scadenza.

Verifica la presenza di schemi non ottimizzati

Prima di progettare uno schema di database ottimale per Spanner del database, considera i tipi di query che verranno eseguiti del database. Schemi non ottimali possono causare problemi di prestazioni durante l'esecuzione alcune query. Questi problemi di prestazioni potrebbero impedire il completamento delle richieste entro la scadenza configurata.

Risoluzione

La progettazione ottimale dello schema dipenderà dalle letture e scritture effettuate del database. Le best practice per la progettazione dello schema e le risorse SQL alle best practice devono essere seguite indipendentemente specifiche dello schema. Seguendo queste guide, eviterai lo schema più comune problemi di progettazione. Alcune altre cause principali di un rendimento scarso sono attribuite la scelta delle chiavi primarie, layout delle tabelle (vedi Utilizzo di tabelle con interleaving per un accesso più rapido), progettazione dello schema (consulta l'articolo sull'ottimizzazione dello schema per il rendimento), e le prestazioni del nodo configurato l'istanza di Spanner (vedi la Panoramica delle prestazioni di Spanner.

Verifica la presenza di hotspot

Poiché Spanner è un database distribuito, la progettazione dello schema deve essere tenuto in considerazione per evitare gli hotspot. Ad esempio, creare in modo monotonico L'aumento delle colonne limiterà il numero di suddivisioni utilizzate da Spanner per distribuire il carico di lavoro in modo uniforme. Questi colli di bottiglia possono in timeout. Inoltre, puoi usare Key Visualizer per risolvere i problemi di prestazioni causati dagli hotspot.

Risoluzione

Fai riferimento alle risoluzioni identificate nella sezione precedente Verificare la presenza di errori non per risolvere il problema. Riprogetta la tua schema del database e utilizza indici con interleaving per evitare indici che potrebbero causare hotspotting. Se seguendo questi passaggi non per limitare il problema, consulta la guida alla scelta di una chiave primaria per evitare gli hotspot. Infine, evita modelli di traffico non ottimali, come letture di ampi intervalli che potrebbero impedire la suddivisione basata sul carico.

Verificare la presenza di timeout configurati in modo errato

Le librerie client forniscono valori predefiniti per timeout ragionevoli per tutte le richieste in Spanner. Tuttavia, queste configurazioni predefinite potrebbero dover e adattati al carico di lavoro specifico. Vale la pena osservare il costo e modificare le scadenze per adattarle al caso d'uso specifico.

Risoluzione

Le impostazioni predefinite per i timeout sono adatte alla maggior parte dei casi d'uso. Gli utenti possono eseguire l'override di queste configurazioni (consulta la guida al timeout e ai nuovi tentativi personalizzati), ma non è consigliabile utilizzare timeout più restrittivi rispetto a quelli predefiniti. Se decidi di modificare il timeout, impostalo sulla quantità di tempo effettiva in cui l'applicazione è disposta ad attendere il risultato. Puoi sperimentare con modelli i timeout configurati, ma non impostare mai un timeout più breve del tempo che l'applicazione è disposta ad attendere, poiché questo causerebbe l'esecuzione dell'operazione nuovi tentativi con maggiore frequenza.

Problemi relativi all'API Admin

Le richieste API Admin sono operazioni costose rispetto alle richieste API di dati. Le richieste degli amministratori come CreateInstance, CreateDatabase o CreateBackups possono richiede molti secondi prima di restituire una risposta. Client Spanner le librerie impostano scadenze di 60 minuti per entrambe le istanze instance e database richieste dell'amministratore. Questo serve a garantire che il server abbia la possibilità di completare prima che il client esegua un nuovo tentativo o abbia esito negativo.

Risoluzione

Se utilizzi la libreria client di Google Spanner per accedere all'API Admin, assicurati che la libreria client sia aggiornata e utilizzi la versione completamente gestita. Se accedi all'API Spanner direttamente tramite una libreria client che hai creato, assicurati di non avere scadenze più rigide rispetto alle impostazioni predefinite (60 minuti) dell'istanza e database richieste dell'amministratore.

Problemi con la console Google Cloud

Le query emesse dalla pagina Spanner Studio della console Google Cloud non possono per superare i cinque minuti. Se crei una query costosa che richiede più di cinque minuti per l'esecuzione, viene visualizzato il seguente messaggio di errore:

Screenshot del messaggio di errore "Superata la scadenza della console Google Cloud"

Il backend annullerà la query non riuscita e potrebbe essere eseguito il rollback della transazione se necessario.

Risoluzione

Puoi riscrivere la query utilizzando la guida alle best practice per le query SQL.

Problemi relativi a Dataflow

In Apache Beam, la configurazione predefinita del timeout è di due ore per le operazioni di lettura e 15 secondi per le operazioni di commit. Queste configurazioni consentono operazioni più lunghe quando rispetto ai timeout di scadenza della libreria client autonoma. Tuttavia, è ancora possibile ricevere un errore di timeout e di superamento della scadenza quando gli elementi di lavoro sono troppo grandi. Se necessario, puoi personalizzare il commit Apache Beam la configurazione del timeout.

Risoluzione

Se si verifica un errore relativo al superamento della scadenza nei passaggi ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, controlla tabella delle statistiche delle query per scoprire quale query ha analizzato un numero elevato di righe. Poi modifica per cercare di ridurre il tempo di esecuzione.

Un altro esempio di errore di superamento della scadenza Dataflow è mostrato in il seguente messaggio di eccezione:

exception:
     org.apache.beam.sdk.util.UserCodeException:
     com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED:
     io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after
     3599.999905380s.
     [remote_addr=batch-spanner.googleapis.com/172.217.5.234:443] at
 org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output(GroupAlsoByWindowsParDoFn.java:184)

Questo timeout è dovuto al fatto che gli elementi di lavoro sono troppo grandi. Nell'esempio precedente, i due consigli seguenti potrebbero aiutarti. Innanzitutto, puoi provare ad attivare il servizio di shuffle se non è ancora abilitato. In secondo luogo, puoi provare a modificare configurazioni nella lettura del database, come maxPartitions e partitionSizeBytes. Per ulteriori informazioni, visita la pagina PartitionOptions. per provare a ridurre la dimensione dell'elemento di lavoro. Trovi un esempio di come farlo in questo modello Dataflow.

La scadenza aggiuntiva ha superato le risorse per la risoluzione dei problemi

Se visualizzi ancora l'errore DEADLINE_EXCEEDED dopo aver completato passaggi per la risoluzione dei problemi, apri una richiesta di assistenza si verificano i seguenti scenari:

  • Latenza elevata di Google Front End (GFE), ma bassa latenza delle richieste API Spanner
  • Una latenza elevata per le richieste API Spanner, ma una bassa latenza delle query

Puoi anche consultare le seguenti risorse per la risoluzione dei problemi: