Risolvi i problemi di latenza

Come qualsiasi sistema di database, Bigtable può riscontrare problemi di latenza. Questo documento illustra le cause comuni dei problemi di latenza in Bigtable e spiega come risolverli.

Diagnostica e risolvi i problemi di latenza di Bigtable utilizzando i passaggi per la risoluzione dei problemi nelle sezioni seguenti:

Comprendi le cause della latenza elevata

I seguenti fattori contribuiscono ai problemi di latenza in Bigtable:

  • Latenza del server. La misurazione della latenza del server inizia quando Bigtable riceve la richiesta e termina quando Bigtable invia l'ultimo byte di dati al client. Per le richieste di grandi quantità di dati, la capacità del client di consumare la risposta può influire sulla latenza del server.
  • Latenze delle operazioni misura il tempo end-to-end totale per un'operazione Bigtable, inclusi tutti i nuovi tentativi. Questa metrica monitora l'andata e ritorno dal client a Bigtable e di nuovo al client. La latenza dell'applicazione, la connessione di rete, la latenza della libreria client di Bigtable e le latenze del server influiscono tutte sulla latenza delle operazioni.
  • I pattern di workload e richieste possono aumentare la latenza non solo a causa di un problema dell'infrastruttura, ma anche a causa di una modifica del pattern di lavoro richiesto dall'applicazione. Ad esempio, una query di scansione generata dinamicamente che in precedenza analizzava cento righe ora ne analizza un milione a causa di una recente importazione di dati o di una modifica della logica dell'applicazione. Anche se il sistema potrebbe funzionare in modo efficiente, l'aumento significativo della quantità di lavoro per una singola operazione comporta un tempo di esecuzione più lungo, che Bigtable percepisce come una latenza più elevata.

Prima di iniziare

Per risolvere i problemi di latenza elevata, esegui le seguenti attività:

  • Abilita le metriche lato client per la tua libreria client per ottimizzare le prestazioni e risolvere i problemi.
  • Per ridurre al minimo la latenza di rete, verifica che l'applicazione si trovi nella stessa zona del cluster Bigtable. In questo modo, la distanza di rete tra l'applicazione e il cluster viene ridotta, migliorando i tempi di risposta per le richieste.
  • Raccogli le seguenti informazioni sul tuo ambiente Bigtable:
  • Raccogli le seguenti informazioni sull'ambiente lato client:
  • Raccogli le seguenti informazioni sul problema:

Risolvi i problemi di latenza

Se riscontri problemi di latenza in Bigtable, segui questi passaggi per risolverli:

  1. Controlla la latenza del server: utilizza la pagina Monitoring nella consoleGoogle Cloud per visualizzare la latenza del server. Per saperne di più, consulta Monitora con Cloud Monitoring. Controlla la latenza dell'istanza. Se l'istanza contiene più cluster, suddividi la metrica per cluster. Se osservi un aumento della latenza nei grafici della latenza di lettura o di scrittura o nelle metriche lato client, segui i passaggi per la risoluzione dei problemi di latenza del server nella sezione Risolvi i problemi di latenza del server di questo documento.
  2. Controlla la latenza del client: dopo aver attivato le metriche lato client, cerca bigtable.googleapis.com/client in Metrics Explorer di Cloud Monitoring. Esamina le metriche lato client disponibili. Se noti un aumento della latenza nelle metriche lato client, ma non sul server, esamina l'applicazione e la connessione di rete. Per saperne di più, consulta la sezione Risolvi i problemi di latenza del client di questo documento.

Il seguente diagramma mostra la procedura per la risoluzione dei problemi relativi all'aumento della latenza in Bigtable:

Diagramma di flusso per la risoluzione dei problemi di latenza di Bigtable.
Figura 1. La procedura di risoluzione dei problemi di latenza di Bigtable (fai clic per ingrandire).

Risolvi i problemi di latenza del client

Segui questi passaggi per risolvere i problemi di latenza lato client.

Prima di iniziare

Prima di iniziare la risoluzione dei problemi relativi alla latenza lato client, completa le seguenti attività:

  • Abilita le metriche lato client in Bigtable.
  • Attiva il priming del canale se utilizzi un client Java versione 2.17.1 o precedente. L'aggiornamento dei canali è abilitato per impostazione predefinita a partire dalla versione 2.18.0.
  • Esegui l'iterazione per determinare la dimensione ottimale del pool di connessioni per il tuo workload. Un numero inadeguato o eccessivo di canali può causare latenze elevate dei tentativi.

Controlla le latenze di blocco delle applicazioni

Controlla la metrica Application Blocking Latencies nella console Google Cloud ed esegui una delle seguenti azioni:

  • Se le latenze di blocco dell'applicazione sono elevate e corrispondono all'aumento della latenza segnalato, concentrati sulla risoluzione dei problemi lato client.
  • Se le latenze di blocco dell'applicazione sono elevate e il client è ospitato sull'infrastrutturaGoogle Cloud , ad esempio GKE o Compute Engine, assegna il caso al team di assistenza Google Cloud appropriato.
  • Se le latenze di blocco dell'applicazione sono basse e anche la latenza di gestione di Bigtable è bassa, il collo di bottiglia della latenza si trova probabilmente in un componente intermedio del percorso di rete o di traffico, ad esempio la rete o il frontend di Google. Valuta la possibilità di assegnare il problema al team di networking Google Cloudper ricevere assistenza con un'acquisizione completa dei pacchetti per identificare il collo di bottiglia della latenza.

Risolvi i problemi di latenza elevata delle operazioni

  1. Se connectivity_error_count è elevato, l'applicazione ha difficoltà a raggiungere il frontend di Google. Imposta timeout RPC più bassi in modo che la richiesta possa riprovare su canali diversi.
    • Se il timeout RPC è troppo basso, può anche causare latenze elevate delle operazioni. Determina il timeout RPC P99 tipico durante le normali operazioni. L'impostazione di un valore di timeout RPC più vicino a questo benchmark consente di ottimizzare le prestazioni.
  2. Se retry_count è elevato, controlla il tag di stato attempt_latencies. Se i tentativi non vanno a buon fine con errori DEADLINE_EXCEEDED, la scadenza della richiesta è troppo breve rispetto alla media di attempt_latencies.

Risolvi le richieste in coda nel thread gRPC

Se nessuna delle metriche supera la norma, le richieste potrebbero essere messe in coda nel thread gRPC. Ciò può verificarsi per i seguenti motivi:

  • Le dimensioni del pool di canali sono troppo ridotte e le richieste vengono messe in coda nei canali gRPC. Per saperne di più, consulta Richieste con buffering.
  • L'utilizzo della CPU della VM client è elevato. Un utilizzo elevato della CPU comporta anche l'accodamento delle richieste nel client.

Risolvi i problemi di latenza del server

Segui questi passaggi per risolvere i problemi di latenza lato server.

Determina se il cluster è sovraccarico

  1. Controlla i grafici Read requests e Write requests per verificare se sono presenti variazioni delle QPS.
  2. Controlla il grafico Node count per verificare se sono state apportate modifiche al conteggio dei nodi.
  3. Controlla i grafici Read throughput e Write throughput per verificare se la larghezza di banda è aumentata. Per saperne di più, consulta Informazioni sul rendimento.
  4. Per identificare il modo in cui la CPU viene utilizzata per profilo dell'app, metodo e tabella per risolvere i problemi di prestazioni, consulta il blog post In che modo il tuo cluster Cloud Bigtable utilizza la CPU?
  5. Aumenta il numero di nodi nel cluster interessato. Per saperne di più, consulta Aggiungi o rimuovi nodi manualmente e Scalabilità automatica. Verifica che l'utilizzo medio della CPU rimanga al di sotto della soglia consigliata.

Controlla la presenza di hotspot

Un tablet hot utilizza una percentuale sproporzionatamente elevata della CPU di un nodo rispetto ad altri tablet associati a quel nodo. Questo utilizzo sbilanciato può verificarsi a causa di un volume elevato imprevisto di richieste a un intervallo di righe o di difetti nella progettazione dello schema. Questo utilizzo non bilanciato dei nodi può causare latenze più elevate e ritardi di replica, noti come hotspot.

  1. Osserva gli hotspot nel grafico CPU utilization (hottest node) high granularity.
  2. Per identificare i tablet attivi, utilizza i tablet attivi o lo strumento Key Visualizer.
  3. A differenza dell'utilizzo eccessivo della CPU a livello di cluster, che spesso puoi mitigare aggiungendo più nodi (scalabilità orizzontale), gli hotspot potrebbero richiedere altre tecniche di mitigazione. Queste tecniche includono la modifica del modo in cui crei le chiavi di riga o la modifica dello schema. Per saperne di più, consulta il blog post Elimina gli hotspot in Cloud Bigtable.

Risolvi i problemi di latenza con QPS basse

Bigtable offre il massimo delle prestazioni con tabelle di grandi dimensioni a cui accedi di frequente. Se invii richieste dopo un periodo di inattività, potresti notare una latenza elevata mentre Bigtable ristabilisce le connessioni.

  1. Se i grafici Read requests e Write requests mostrano un numero di QPS basso, aspettati tempi di risposta più lenti.
  2. Riduci i problemi di avvio a freddo seguendo le best practice descritte in Avvii a freddo e QPS basse.

Valuta l'efficienza delle richieste

Valuta l'efficienza delle richieste utilizzando la pagina Pattern di accesso e le statistiche delle query:

  • Utilizza la pagina Pattern di accesso nella console Google Cloud per monitorare la suddivisione dei tipi di query di lettura e scrittura nel tempo (ad esempio letture puntuali, scansioni brevi, scansioni inverse, letture sparse e letture collettive) e confrontare Righe scansionate e Celle visualizzate con Righe restituite e Celle inviate per le tabelle e i profili delle app. Per saperne di più, consulta Analizza i pattern di accesso.
  • Utilizza le statistiche delle query per esaminare il rapporto tra righe visualizzate e righe restituite e tra celle visualizzate e celle restituite per singole richieste di lettura. Migliora l'efficienza delle richieste rivedendo i pattern di query, i filtri o la progettazione dello schema. Per saperne di più, consulta Recupera le statistiche delle query.

Controlla le modifiche alla configurazione o al profilo dell'app

Se il numero di nodi e il throughput rimangono invariati, ma l'utilizzo medio della CPU aumenta, ciò potrebbe essere dovuto a modifiche alle strategie di replica o di garbage collection. Per saperne di più, consulta Replica e prestazioni. Ripristina le modifiche alla configurazione per la replica o la garbage collection.

Assegna il problema all'assistenza Bigtable

Se i passaggi precedenti non risolvono il problema, assegna il caso all'assistenza Bigtable.

Passaggi successivi