Risolvere i problemi relativi agli errori di scadenza di Spanner superata

Questa pagina fornisce una panoramica degli errori di scadenza di Spanner superata: 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.

Un errore di scadenza superata può verificarsi per molti motivi diversi, ad esempio per istanze Spanner sovraccaricate, 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 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 del timeout come la durata massima 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. In questo contesto, le seguenti strategie e operazioni non sono consigliate, poiché sono controproducenti e annullano il comportamento di ripetizione interna di Spanner:

  • Impostare una scadenza troppo breve. Ciò significa che l'operazione non è resiliente agli occasionali aumenti 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.

  • 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, questo può creare un carico aggiuntivo significativo sull'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 applicazione di specificare il tempo di attesa per il completamento di una richiesta prima che venga interrotta 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 Spanner supportate. Le librerie client di Spanner utilizzano impostazioni predefinite per i criteri di timeout e di ripetizione che sono definiti nei seguenti file di configurazione:

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

Come esaminare e risolvere gli errori comuni relativi al superamento della scadenza

Potresti riscontrare errori DEADLINE_EXCEEDED per i seguenti tipi di problemi:

Problemi con le 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 sezioni seguenti descrivono come esaminare e risolvere diversi problemi relativi alle API di accesso ai dati.

Controlla 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 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 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 scoprire di più, consulta 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 con l'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 verificare la presenza di questi pattern di utilizzo non ottimali.

Controllare le 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. Alcuni esempi di query costose includono, a titolo esemplificativo, scansioni complete di una tabella di grandi dimensioni, join tra più tabelle di grandi dimensioni o 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 sulle query e la tabella delle statistiche sulle transazioni. Queste tabelle mostrano informazioni su query e transazioni in esecuzione lenta, ad esempio il numero medio di righe lette, i byte letti in media, il numero medio di righe analizzate 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, consulta la guida alle best practice per le query SQL. Puoi anche utilizzare i dati ottenuti tramite le tabelle di statistiche menzionate in precedenza e i piani di esecuzione per ottimizzare le query e apportare modifiche allo schema ai tuoi database. Queste best practice possono contribuire a ridurre il tempo di esecuzione delle istruzioni, contribuendo potenzialmente a eliminare gli errori di scadenza superata.

Verifica la presenza di conflitti di blocco

Le transazioni Spanner devono acquisire blocchi per eseguire il commit. Le applicazioni in esecuzione con una velocità effettiva elevata possono causare una competizione tra le transazioni per le stesse risorse, aumentando il tempo di attesa per ottenere le chiavi e influendo 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 un conflitto di blocco utilizzando la guida alla risoluzione dei problemi relativi ai tag transazioni.

Risoluzione

Applica queste best practice per ridurre le contese sui blocchi. 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 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.

Controlla 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 più ottimale dipende dalle letture e dalle scritture eseguite sul database. Le guide sulle best practice per la progettazione dello schema e sulle best practice per SQL devono essere seguite indipendentemente dalle specifiche dello schema. Seguendo queste guide, eviterai i problemi di progettazione dello schema più comuni. Altre cause alla base del cattivo rendimento sono attribuite alla scelta delle chiavi primarie, al layout delle tabelle (consulta Utilizzare tabelle interlacciate per un accesso più rapido), alla progettazione dello schema (consulta Ottimizzare lo schema per il rendimento) e al rendimento del nodo configurato all'interno dell'istanza Spanner (consulta la Panoramica del rendimento 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 potrebbero comportare dei timeout. Inoltre, puoi utilizzare lo strumento di visualizzazione delle parole chiave per risolvere i problemi di rendimento causati dagli hotspot.

Risoluzione

Come primo passaggio per risolvere il problema, consulta le soluzioni identificate nella sezione precedente Verificare la presenza di schemi non ottimizzati. Ridisegna lo schema del database e utilizza gli indici interlacciati per evitare indici che potrebbero causare hotspot. Se la procedura descritta non consente di risolvere il problema, consulta la guida alla scelta di una chiave primaria per evitare i problemi relativi agli hotspot. Infine, evita pattern di traffico non ottimali come letture di intervalli di grandi dimensioni che potrebbero impedire la suddivisione in base al carico.

Verificare 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 essere aggiustate in base al tuo carico di lavoro 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 su timeout e tentativi di nuovo invio personalizzati), ma non è consigliabile utilizzare timeout più aggressivi rispetto a quelli predefiniti. Se decidi di modificare il timeout, impostalo sul periodo di tempo effettivo che l'applicazione è disposta ad attendere per 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 con l'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. Le librerie client Spanner impostano scadenze di 60 minuti sia per le richieste degli amministratori di istanze sia per quelle di 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 Spanner di Google per accedere all'API amministratore, assicurati che la libreria client sia aggiornata e che utilizzi la versione più recente. 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 inviate dalla pagina Spanner Studio della console Google Cloud non possono superare i cinque minuti. Se crei una query dispendiosa che richiede più di cinque minuti di esecuzione, viene visualizzato il seguente messaggio di errore:

Screenshot del messaggio di errore relativo alla scadenza superata nella console Google Cloud

Il backend annullerà la query non riuscita e, se necessario, potrebbe essere 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 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 scadenza superata 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 scadenza di Dataflow superata è 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 si è verificato perché gli elementi di lavoro sono troppo grandi. Nell'esempio precedente, i seguenti due consigli potrebbero essere utili. Innanzitutto, puoi provare ad attivare il servizio di riproduzione casuale, se non è ancora attivo. In secondo luogo, puoi provare a modificare le configurazioni nella lettura del database, ad esempio maxPartitions e partitionSizeBytes. Per ulteriori informazioni, 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 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 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 fare riferimento alle seguenti risorse per la risoluzione dei problemi: