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:
- spanner_grpc_service_config.json
- spanner_admin_instance_grpc_service_config.json
- spanner_admin_database_grpc_service_config.json
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
- Problemi relativi alle API di dati
- Problemi relativi all'API Admin
- Problemi della console Google Cloud
- Problemi di Dataflow
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:
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:
- Esaminare la latenza in un componente Spanner con OpenTelemetry
- Risolvere i problemi di regressione delle prestazioni
- Analizzare le query in esecuzione in Spanner per diagnosticare i problemi di prestazioni