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.

Durante l'accesso alle API Spanner, le richieste potrebbero non riuscire a causa di DEADLINE_EXCEEDED errori. Questo errore indica che non è stata ricevuta una risposta entro il periodo di timeout configurato.

Un errore di scadenza superata può verificarsi per molti diversi motivi, ad esempio istanze Spanner con sovraccarico, schemi non ottimizzati o query non ottimizzate. Questa pagina descrive gli scenari comuni in cui si verifica un errore di superamento della scadenza e fornisce una guida su come analizzare e risolvere questi problemi.

La scadenza e la filosofia dei nuovi tentativi di Spanner

La filosofia della scadenza e dei nuovi tentativi di Spanner è diversa da molti altri sistemi. In Spanner, devi specificare una scadenza di timeout come tempo massimo in cui una risposta è utile. Impostare una scadenza artificialmente breve solo per riprovare immediatamente la stessa operazione non è consigliata, poiché ciò causerebbe situazioni in cui le operazioni non vengono mai completate. In questo contesto, le strategie e le operazioni riportate di seguito non sono consigliate, in quanto sono controproduttive e annullano il comportamento di ripetizione dei tentativi interno di Spanner:

  • 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 che scada. Imposta invece una scadenza che corrisponde al tempo massimo in cui una risposta è utile.

  • Impostare una scadenza troppo lunga e annullare l'operazione prima che la scadenza superi. Questo porta a nuovi tentativi e sprechi di lavoro a ogni tentativo. I dati aggregati possono creare un carico aggiuntivo significativo sulla tua istanza.

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

Quando utilizzi una delle librerie client di Spanner, il livello gRPC sottostante si occupa delle comunicazioni, del marshalling, dell'annullamento del marshalling 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 la richiesta venga terminata con l'errore di superamento della scadenza.

La guida alla configurazione del timeout mostra come specificare scadenze (o timeout) in ciascuna delle librerie client di Spanner supportate. Le librerie client di Spanner utilizzano le impostazioni dei criteri di timeout e dei nuovi tentativi predefiniti, definite nei seguenti file di configurazione:

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

Per evitare problemi con l'API di accesso ai dati, un'istanza di Spanner deve essere configurata in modo appropriato per i carichi di lavoro specifici. Le seguenti sezioni descrivono come indagare e risolvere diversi problemi relativi alle 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 stato integro 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 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 viaggia dal client ai server Spanner e viceversa, è necessario effettuare diversi hop di rete: dalla libreria client a Google Front End (GFE), da 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 notare errori di superamento della scadenza.

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

Risoluzione

Una volta ottenuta l'analisi della latenza, puoi utilizzare le metriche per diagnosticare la latenza, capire il motivo e trovare soluzioni.

Problemi relativi all'API di dati

Alcuni pattern di utilizzo non ottimali dell'API di dati di Spanner potrebbero causare errori di superamento della scadenza. Questa sezione fornisce linee guida su come verificare questi pattern di utilizzo non ottimali.

Verificare la presenza di query costose

Il tentativo di eseguire query costose che non vengono eseguite entro la scadenza del timeout configurata nelle librerie client potrebbe causare un errore di superamento della scadenza. Alcuni esempi di query costose includono, a titolo esemplificativo, analisi complete di una tabella di grandi dimensioni, join incrociati 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 query costose utilizzando la tabella delle statistiche delle query e la tabella delle statistiche delle transazioni. Queste tabelle mostrano informazioni sulle query e sulle transazioni con esecuzione lenta, come il numero medio di righe lette, la media di byte letti, il numero medio di righe analizzate e altro ancora. Inoltre, puoi generare piani di esecuzione delle query per ispezionare 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 e i piani di esecuzione per ottimizzare le query e apportare modifiche allo schema dei database. Queste best practice possono aiutare a ridurre il tempo di esecuzione delle istruzioni, contribuendo potenzialmente a eliminare gli errori di superamento della scadenza.

Verificare la contesa del blocco

Le transazioni Spanner devono acquisire blocchi per il commit. Le applicazioni in esecuzione con velocità effettiva elevata possono far competere le transazioni per le stesse risorse, causando un aumento dell'attesa per ottenere i blocchi e con ripercussioni sulle prestazioni complessive. Di conseguenza, le scadenze per le richieste di lettura o scrittura potrebbero essere state superate.

Puoi trovare la causa principale delle transazioni di lettura-scrittura ad alta latenza utilizzando la tabella delle statistiche di blocco e leggendo il seguente post del blog. Nella tabella delle statistiche di blocco puoi trovare le chiavi di riga con i tempi di attesa per il 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 con i tag di transazione.

Risoluzione

Applica queste best practice per ridurre i conflitti di blocco. Inoltre, utilizza le transazioni di sola lettura per casi d'uso di letture semplici al fine di evitare conflitti di blocco con le scritture. L'utilizzo delle transazioni di lettura-scrittura deve essere riservato alle operazioni di scrittura o ai flussi di lavoro misti di lettura e scrittura. Seguire questi passaggi dovrebbe migliorare la latenza complessiva del tempo di esecuzione delle transazioni e ridurre gli errori di superamento della scadenza.

Verifica la presenza di schemi non ottimizzati

Prima di progettare uno schema ottimale per il database Spanner, dovresti prendere in considerazione i tipi di query che verranno eseguiti nel database. 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 nel database. Seguire le best practice per la progettazione degli schemi e le best practice SQL a prescindere dalle specifiche dello schema. Seguendo queste guide, eviterai i problemi più comuni di progettazione dello schema. Alcune altre cause principali delle scarse prestazioni sono attribuite alla scelta delle chiavi primarie, al layout della tabella (consulta Utilizzare le 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 la Panoramica delle prestazioni di Spanner.

Verifica 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 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 portare a timeout. Inoltre, puoi utilizzare Key Visualizer per risolvere i problemi di prestazioni causati dagli hotspot.

Risoluzione

Come primo passo per risolvere questo problema, consulta le risoluzioni identificate nella sezione precedente Verificare la presenza di schemi non ottimizzati. Riprogetta lo schema del database e utilizza gli indici con interleaving per evitare indici che potrebbero causare hotspot. Se questi passaggi non risolvono il problema, consulta la guida relativa alla scelta di una chiave primaria per evitare gli hotspot. Infine, evita pattern 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, potrebbe essere necessario regolare queste configurazioni predefinite in base al carico di lavoro specifico. Vale la pena osservare il costo delle query e modificare le scadenze in base 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 è sconsigliato utilizzare timeout più aggressivi rispetto a quelli predefiniti. Se decidi di modificare il timeout, impostalo sul 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, perché questo causerebbe nuovi tentativi dell'operazione 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 impiegare molti secondi prima di restituire una risposta. Le librerie client di Spanner impostano scadenze di 60 minuti per le richieste degli amministratori di instance e database. Questo garantisce che il server abbia la possibilità di completare la richiesta 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 amministratore, assicurati che la libreria client sia aggiornata e che utilizzi la versione più recente. 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 istanza e database.

Problemi con la console Google Cloud

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 essere eseguita, verrà 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, 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 relativi a 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 superamento della scadenza 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 scadenza superata nei passaggi ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, consulta la tabella delle statistiche delle query per scoprire quale query ha analizzato un numero elevato di righe. Poi modifica le query per cercare di ridurre il tempo di esecuzione.

Un altro esempio di errore di superamento della scadenza 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 suggerimenti seguenti potrebbero aiutarti. Innanzitutto, puoi provare ad abilitare 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 maggiori 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.

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

Se visualizzi ancora l'errore DEADLINE_EXCEEDED dopo aver completato i passaggi per la risoluzione dei problemi, apri una richiesta di assistenza se 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: