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 di erroriDEADLINE_EXCEEDED
. Questo errore indica che non è stata ricevuta una risposta 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. Questa pagina descrive gli scenari comuni in cui si verifica un errore di scadenza superata e fornisce una guida su come esaminare e risolvere questi problemi.
Filosofia di Spanner relativa alla scadenza e ai tentativi di ripetizione
La filosofia di Spanner relativa alla scadenza e ai tentativi di nuovo invio è diversa da quella di molti altri sistemi. In Spanner, devi specificare una scadenza di timeout come il periodo di tempo massimo in cui una risposta è utile. Non è consigliabile impostare una scadenza artificiosamente breve solo per riprovare immediatamente la stessa operazione, in quanto ciò potrebbe portare 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 non è resiliente agli aumenti occasionali della latenza in coda e non può essere completata prima del timeout. Imposta invece una scadenza che corrisponda al periodo di tempo massimo in cui una risposta è utile.
Impostare una scadenza troppo lunga e annullare l'operazione prima del giorno oltre la scadenza. 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'è un errore di scadenza superata?
Quando utilizzi una delle librerie client Spanner, il livello gRPC sottostante si occupa di comunicazione, marshalling, unmarshalling e 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 all'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 in modo appropriato per i tuoi carichi di lavoro specifici per evitare problemi con le API di accesso ai dati. 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 supera la soglia di sicurezza 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 la procedura per ridurre l'utilizzo della CPU dell'istanza, consulta Ridurre l'utilizzo della CPU.
Controlla la suddivisione della latenza end-to-end della richiesta
Quando una richiesta passa dal client ai server Spanner e viceversa, devono essere eseguiti diversi hop di rete: dalla libreria client a Google Front End (GFE), dal GFE al frontend dell'API Spanner e infine dal frontend dell'API Spanner al database Spanner. Se si verificano problemi di rete in una di queste fasi, potresti visualizzare 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 scoprire dove si verifica la latenza in Spanner, consulta identificare dove si verifica la latenza in Spanner.
Risoluzione
Una volta ottenuta l'analisi dettagliata della latenza, puoi utilizzare le metriche per diagnosticare la latenza, capire perché si verifica e trovare soluzioni.
Problemi relativi all'API di dati
Alcuni pattern di utilizzo non ottimali dell'API Data di Spanner potrebbero causare errori di scadenza superata. Questa sezione fornisce linee guida su come per verificare la presenza di modelli di utilizzo non ottimali.
Controllare la presenza di query costose
Il tentativo di eseguire query complesse che non vengono eseguite entro la scadenza del timeout configurata nelle librerie client potrebbe comportare un errore di scadenza superata. 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 le 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 esaminare ulteriormente la modalità di 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.
Verifica la presenza di conflitti di blocco
Le transazioni Spanner devono acquisire blocchi per 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. Ciò potrebbe comportare il superamento delle scadenze per eventuali richieste di lettura o scrittura.
Puoi trovare la causa principale delle transazioni di lettura/scrittura con latenza elevata utilizzando la tabella delle statistiche dei blocchi e consultando il seguente post del blog. Nella tabella delle statistiche dei blocchi puoi trovare le chiavi di riga con i tempi di attesa del blocco più elevati.
Questa guida alla risoluzione dei problemi relativi ai conflitti di blocco spiega come trovare le transazioni che accedono alle colonne coinvolte nel conflitto di blocco. 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 le contese sui blocchi. Inoltre, utilizza le transazioni di sola lettura. per i casi d'uso di letture semplici, per evitare conflitti di blocco con le scritture. L'utilizzo delle transazioni di lettura/scrittura deve essere riservato alle scritture o ai flussi di lavoro misti di lettura/scrittura. Se segui questi passaggi, dovresti migliorare la latenza complessiva del tempo di esecuzione della transazione e ridurre gli errori di scadenza superata.
Verifica la presenza di schemi non ottimizzati
Prima di progettare uno schema di database ottimale per il tuo database Spanner, devi considerare i tipi di query che verranno eseguite nel database. Gli schemi non ottimali possono causare problemi di prestazioni durante l'esecuzione di 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.
Controllare la presenza di hotspot
Poiché Spanner è un database distribuito, la progettazione dello schema deve tenere conto della prevenzione degli hotspot. Ad esempio, la creazione di colonne con valori in aumento monotonico limiterà il numero di suddivisioni con cui Spanner può lavorare per distribuire il carico di lavoro in modo uniforme. Questi colli di bottiglia possono in timeout. Inoltre, puoi utilizzare lo strumento di visualizzazione delle parole chiave per risolvere i problemi di rendimento causati dagli hotspot.
Risoluzione
Fai riferimento alle risoluzioni identificate nella sezione precedente Verificare la presenza di errori non per risolvere il problema. Ridisegna lo schema del database e utilizza gli indici interlacciati per evitare indici che potrebbero causare hotspot. 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 impediscono la suddivisione basata sul carico.
Controlla la presenza di timeout configurati in modo errato
Le librerie client forniscono valori predefiniti ragionevoli per i timeout 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 cambiare il timeout, impostalo sulla quantità di tempo effettiva in cui l'applicazione è disposta ad attendere il risultato. Puoi fare esperimenti con timeout configurati più lunghi, ma non impostare mai un timeout più breve del tempo effettivo che l'applicazione è disposta ad attendere, in quanto l'operazione verrà ripetuta più di frequente.
Problemi relativi all'API Admin
Le richieste dell'API Admin sono operazioni costose rispetto alle richieste dell'API di dati.
Le richieste amministrative come CreateInstance
, CreateDatabase
o CreateBackups
possono richiedere 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. In questo modo, il server ha la possibilità di completare la richiesta prima che il client riprovi o non riesca.
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 biblioteca client che hai creato, assicurati di non avere impostazioni di scadenza più aggressive rispetto a quelle predefinite (60 minuti) per le richieste degli amministratori dell'istanza e del database.
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 dispendiosa che richiede più di cinque minuti di 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 del timeout predefinita è di due ore per le operazioni di lettura e di 15 secondi per le operazioni di commit. Queste configurazioni consentono operazioni più lunghe rispetto ai timeout delle scadenze della libreria client autonoma. Tuttavia, è ancora possibile ricevere un errore di timeout e di scadenza quando gli elementi di lavoro sono troppo grandi. Se necessario, puoi personalizzare la configurazione del timeout del commit di Apache Beam.
Risoluzione
Se si verifica un errore di scadenza superata nei passaggi ReadFromSpanner / Execute
query / Read from Spanner / Read from Partitions
, controlla la
tabella delle statistiche sulle query
per scoprire quale query ha scansionato un numero elevato di righe. A questo punto, modifica queste query per provare a 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 si è verificato perché 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 le configurazioni nella lettura del database, ad esempio maxPartitions
e
partitionSizeBytes
. Per ulteriori informazioni, visita la pagina PartitionOptions
.
per provare a ridurre la dimensione
dell'elemento di lavoro. Un esempio di come eseguire questa operazione è disponibile in questo modello Dataflow.
Risorse per la risoluzione dei problemi relativi al superamento della scadenza
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:
- Una latenza elevata del front-end di Google, ma una latenza bassa delle richieste dell'API Spanner
- Una latenza elevata delle richieste all'API Spanner, ma una latenza di query bassa
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 contribuire a diagnosticare i problemi di prestazioni