Questa pagina fornisce una panoramica degli errori di scadenza superata di Spanner: cosa sono, perché si verificano e come risolvere i problemi e risolverli.
Quando accedi alle API Spanner, le richieste potrebbero non riuscire a causa di errori DEADLINE_EXCEEDED. Questo errore indica che non è stata ricevuta una risposta entro il periodo di timeout configurato.
Un errore di scadenza superata potrebbe verificarsi per molti motivi diversi, ad esempio istanze Spanner sovraccariche, schemi non ottimizzati o query non ottimizzate. Questa pagina descrive gli scenari comuni in cui si verifica un errore di scadenza superata e fornisce una guida su come analizzare e risolvere questi problemi.
Filosofia di Spanner in merito a scadenze e nuovi tentativi
La filosofia di Spanner in merito a scadenze e nuovi tentativi è diversa da quella di molti altri sistemi. In Spanner, devi specificare una scadenza di timeout come tempo massimo in cui una risposta è utile. Non è consigliabile impostare una scadenza artificialmente breve solo per riprovare immediatamente la stessa operazione, poiché ciò porterà a situazioni in cui le operazioni non vengono mai completate. In questo contesto, le seguenti strategie e operazioni non sono consigliate; sono controproducenti e annullano il comportamento di ripetizione interno di Spanner:
Impostare una scadenza troppo breve. Ciò significa che l'operazione non è resiliente agli aumenti occasionali della latenza finale e non può essere completata prima del timeout. Imposta invece una scadenza che corrisponda al tempo massimo entro il quale una risposta è utile.
Impostazione di una scadenza troppo lunga e annullamento dell'operazione prima del superamento della scadenza. Ciò comporta nuovi tentativi e lavoro sprecato a ogni tentativo. Nel complesso, ciò può creare un carico aggiuntivo significativo sull'istanza.
Che cos'è un errore di scadenza superata?
Quando utilizzi una delle librerie client di Spanner, il livello gRPC sottostante si occupa della comunicazione, del marshalling, dell'unmarshalling e dell'applicazione delle scadenze. Le scadenze consentono alla tua applicazione di specificare per quanto tempo è disposta ad attendere il completamento di una richiesta prima che questa venga terminata con l'errore di scadenza superata.
La guida alla configurazione del timeout mostra come specificare le scadenze (o i timeout) in ciascuna delle librerie client di Spanner supportate. Le librerie client di Spanner utilizzano le impostazioni predefinite delle policy di timeout e di ripetizione dei tentativi, definite nei seguenti file di configurazione:
- spanner_grpc_service_config.json
- spanner_admin_instance_grpc_service_config.json
- spanner_admin_database_grpc_service_config.json
Per saperne di più sulle scadenze gRPC, consulta gRPC e scadenze.
Come esaminare e risolvere gli errori comuni di scadenza superata
Potresti riscontrare errori DEADLINE_EXCEEDED per i seguenti tipi di problemi:
- Problemi relativi all'API Data Access
- Problemi relativi all'API di dati
- Problemi relativi all'API Admin
- Problemi della consoleGoogle Cloud
- Problemi di Dataflow
Problemi relativi all'API di accesso ai dati
Un'istanza Spanner deve essere configurata in modo appropriato per i tuoi workload specifici per evitare problemi con l'API di accesso ai dati. Le sezioni seguenti descrivono come esaminare e risolvere i diversi problemi relativi all'API Data Access.
Controlla il carico della CPU dell'istanza Spanner
La latenza delle richieste può aumentare in modo significativo quando l'utilizzo della CPU supera la soglia di integrità consigliata. Puoi controllare l'utilizzo della CPU di Spanner nella console di monitoraggio fornita nella console Google Cloud . Puoi anche creare avvisi in base all'utilizzo della CPU dell'istanza.
Risoluzione
Per i passaggi per ridurre l'utilizzo della CPU dell'istanza, consulta Riduzione dell'utilizzo della CPU.
Controlla la suddivisione della latenza end-to-end della richiesta
Quando una richiesta viaggia 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; infine, dal frontend dell'API Spanner al database Spanner. Se si verificano problemi di rete in una di queste fasi, potresti visualizzare errori di scadenza superata.
È possibile acquisire la latenza in ogni fase. Per scoprire di più, consulta Punti di latenza in una richiesta Spanner. Per scoprire dove si verifica la latenza in Spanner, consulta Individua il punto in cui si verifica la latenza in Spanner.
Risoluzione
Una volta ottenuta la suddivisione della latenza, puoi utilizzare le metriche per diagnosticare la latenza, capire perché si verifica e trovare soluzioni.
Problemi con l'API di dati
Alcuni pattern di utilizzo non ottimali dell'API di dati di Spanner potrebbero causare errori di scadenza superata. Questa sezione fornisce linee guida su come verificare la presenza di questi pattern di utilizzo non ottimali.
Controlla se sono presenti query costose
Il tentativo di eseguire query costose che non vengono eseguite entro la scadenza del timeout configurata nelle librerie client potrebbe comportare un errore di scadenza superata. Alcuni esempi di query costose includono, a titolo esemplificativo, scansioni complete di una tabella di grandi dimensioni, cross join su più tabelle di grandi dimensioni o l'esecuzione di una query con un predicato su una colonna non chiave (anche una scansione completa della tabella).
Puoi esaminare le query costose utilizzando la tabella delle statistiche delle query e la tabella delle statistiche delle transazioni. Queste tabelle mostrano informazioni su query e transazioni con esecuzione lenta, come il numero medio di righe lette, i byte medi letti, il numero medio di righe analizzate e altro ancora. Inoltre, puoi generare piani di esecuzione delle query per esaminare ulteriormente il modo in cui vengono eseguite le 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 e i piani di esecuzione per ottimizzare le query e apportare modifiche allo schema dei tuoi database. Queste best practice possono contribuire a ridurre il tempo di esecuzione delle istruzioni, aiutando 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 in esecuzione con un throughput elevato possono causare la competizione delle transazioni per le stesse risorse, con un conseguente aumento dell'attesa per ottenere i blocchi e un impatto sulle prestazioni complessive. Ciò potrebbe comportare il superamento delle scadenze per le richieste di lettura o scrittura.
Puoi trovare la causa principale delle transazioni di lettura e scrittura con latenza elevata utilizzando la tabella delle statistiche sui blocchi e consultando il seguente blog post. Nella tabella delle statistiche di blocco, puoi trovare le chiavi di riga con i tempi di attesa di 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 un conflitto di blocchi utilizzando la guida alla risoluzione dei problemi con i tag delle transazioni.
Risoluzione
Applica queste best practice per ridurre i conflitti di blocco. Inoltre, utilizza le transazioni di sola lettura per i casi d'uso di lettura semplice per evitare conflitti di blocco con le scritture. L'utilizzo di transazioni di lettura/scrittura deve essere riservato alle scritture o ai flussi di lavoro di lettura/scrittura misti. Seguendo questi passaggi, dovresti migliorare la latenza complessiva del tempo di esecuzione delle transazioni 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 dello schema ottimale dipende dalle letture e dalle scritture eseguite nel database. Le guide alle best practice di progettazione dello schema e alle best practice SQL devono essere seguite indipendentemente dalle specifiche dello schema. Seguendo queste guide, eviterai i problemi di progettazione dello schema più comuni. Altre cause principali di prestazioni scadenti sono attribuite alla scelta delle chiavi primarie, al layout della tabella (consulta Utilizzo di tabelle con interleaving per un accesso più rapido), alla progettazione dello schema (consulta Ottimizzazione dello schema per le prestazioni) e alle prestazioni del nodo configurato all'interno dell'istanza Spanner (consulta Panoramica delle prestazioni di Spanner).
Controlla 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 che aumentano in modo monotono limiterà il numero di suddivisioni che Spanner può utilizzare per distribuire il workload in modo uniforme. Questi colli di bottiglia potrebbero causare timeout. Inoltre, puoi utilizzare Key Visualizer per risolvere i problemi di prestazioni causati dagli hotspot.
Risoluzione
Come primo passaggio per risolvere questo problema, consulta le soluzioni identificate nella sezione precedente Verifica la presenza di schemi non ottimizzati. Riprogetta lo schema del database e utilizza indici con interleaving per evitare indici che potrebbero causare hotspotting. Se questi passaggi non risolvono il problema, consulta la guida alla scelta di una chiave primaria per evitare gli hotspot. Infine, evita pattern di traffico non ottimali, come letture di intervalli di grandi dimensioni, che potrebbero impedire la suddivisione basata sul carico.
Verifica la presenza di timeout configurati in modo errato
Le librerie client forniscono valori predefiniti ragionevoli per i timeout di tutte le richieste in Spanner. Tuttavia, queste configurazioni predefinite potrebbero dover essere adattate al tuo workload specifico. Vale la pena osservare il costo delle query e modificare le scadenze in modo che siano adatte al tuo 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 ai timeout e ai nuovi tentativi personalizzati), ma non è consigliabile utilizzare timeout più aggressivi di quelli predefiniti. Se decidi di modificare il timeout, impostalo sul tempo effettivo che l'applicazione è disposta ad attendere per il risultato. Puoi sperimentare timeout configurati più lunghi, ma non impostare mai un timeout più breve del tempo effettivo che l'applicazione è disposta ad attendere, poiché ciò comporterebbe un nuovo tentativo dell'operazione più frequente.
Problemi relativi all'API Admin
Le richieste API Admin sono operazioni costose rispetto alle richieste API di dati.
Le richieste di amministrazione come CreateInstance, CreateDatabase o CreateBackups possono richiedere molti secondi prima di restituire una risposta. Le librerie client di Spanner impostano scadenze di 60 minuti per le richieste degli amministratori di istanze e database. 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 di amministrazione, assicurati che la libreria client sia aggiornata e utilizzi l'ultima versione. Se accedi all'API Spanner direttamente tramite una libreria client che hai creato, assicurati di non avere impostazioni di scadenza più aggressive rispetto alle impostazioni predefinite (60 minuti) per le richieste dell'amministratore di istanze e database.
Google Cloud problemi con la console
Le query eseguite dalla pagina Spanner Studio della console Google Cloud non possono 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, se necessario, verrà eseguito il rollback della transazione.
Risoluzione
Puoi riscrivere la query utilizzando la guida alle best practice per le query SQL.
Problemi di Dataflow
In Apache Beam, la configurazione predefinita del timeout è 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, è comunque possibile ricevere un errore di timeout e di scadenza superata quando gli elementi di lavoro sono troppo grandi. Se necessario, puoi personalizzare la configurazione del timeout di commit di Apache Beam.
Risoluzione
Se si verifica un errore di superamento della scadenza nei passaggi ReadFromSpanner / Execute
query / Read from Spanner / Read from Partitions, controlla la tabella delle statistiche delle query per scoprire quale query ha analizzato un numero elevato di righe. Poi, modifica queste query per provare a ridurre il tempo di esecuzione.
Un altro esempio di errore di superamento della scadenza di Dataflow è mostrato nel 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 essere utili. Innanzitutto, puoi provare ad attivare il servizio di shuffling se non è ancora attivo. In secondo luogo, puoi provare a modificare le configurazioni nella lettura del database, ad esempio maxPartitions e partitionSizeBytes. Per saperne di più, consulta PartitionOptions
per provare a ridurre le dimensioni dell'elemento di lavoro. Un esempio di come eseguire questa operazione è disponibile in questo modello Dataflow.
Risorse aggiuntive per la risoluzione dei problemi relativi al superamento della scadenza
Se continui a visualizzare un errore DEADLINE_EXCEEDED dopo aver completato i passaggi per la risoluzione dei problemi, apri una richiesta di assistenza se si verificano i seguenti scenari:
- Una latenza Google Front End (GFE) elevata, ma una latenza delle richieste API Spanner bassa
- Una latenza delle richieste API Spanner elevata, ma una latenza delle query bassa
Puoi anche consultare le seguenti risorse per la risoluzione dei problemi:
- Esamina la latenza in un componente Spanner con OpenTelemetry
- Risolvi i problemi relativi alle regressioni delle prestazioni delle query
- Analizza le query in esecuzione in Spanner per diagnosticare i problemi di prestazioni