Come posso risolvere i problemi di latenza elevata quando utilizzo ElastiCache per Redis?

Breve descrizione

Di seguito sono riportati i motivi più comuni per problemi di latenza elevata o timeout in ElastiCache per Redis:

• Latenza causata da comandi lenti.
• Elevato utilizzo della memoria con conseguente aumento dello swap.
• Latenza causata da problemi di rete.
• Problemi di latenza lato client.
• Eventi dei cluster ElastiCache.

Risoluzione

Latenza causata da comandi lenti

Redis è principalmente a thread singolo. Quindi, quando si verifica una lentezza nel servire una richiesta, tutti gli altri client devono attendere di poter essere serviti. Questo tempo di attesa va ad aggiungersi alle varie latenze dei comandi. I comandi Redis hanno anche una complessità temporale definita utilizzando la notazione Big O.

Usa le metriche di Amazon CloudWatch fornite da ElastiCache per monitorare la latenza media per classi di comandi diverse. È importante notare che le operazioni comuni di Redis vengono calcolate valutandone la latenza in microsecondi. Le metriche di CloudWatch vengono campionate ogni minuto e le metriche di latenza mostrano un aggregato di più comandi. Pertanto, un singolo comando può causare risultati imprevisti, come i timeout, senza che i grafici delle metriche mostrino cambiamenti di rilievo. In queste situazioni, utilizza il comando SLOWLOG per determinare quali comandi richiedono più tempo per essere completati. Connettiti al cluster ed esegui il comando slowlog get 128 in redis-cli per recuperare l'elenco. Per maggiori informazioni, consulta Come posso attivare il registro Redis Slow in un cluster di cache ElastiCache per Redis?

In CloudWatch potresti anche notare un aumento della metrica EngineCPUUtilization a causa dei comandi lenti che bloccano il motore Redis. Per maggiori informazioni, consulta Perché riscontro un utilizzo elevato o crescente della CPU nel cluster ElastiCache per Redis?

Esempi di comandi complessi includono:

• CHIAVI negli ambienti di produzione su un set di dati di grandi dimensioni, durante la valutazione dell'intero spazio delle chiavi alla ricerca di un modello specifico.
• Script LUA di lunga durata.

Utilizzo elevato della memoria che porta a un aumento dello scambio

Redis inizia a scambiare le pagine quando c'è una maggiore pressione di memoria sul cluster utilizzando più memoria di quella disponibile. I problemi di latenza e timeout aumentano quando le pagine di memoria vengono trasferite da e verso l'area di scambio. Di seguito sono riportate le indicazioni nelle metriche di CloudWatch relative all'aumento dello scambio:

• Aumento dello SwapUsage.
• FreeableMemory molto bassa.
• BytesUsedForCache molto elevati e metriche DatabaseMemoryUsagePercentage.

SwapUsage è una metrica a livello di host che indica la quantità di memoria scambiata. È normale che questa metrica mostri valori diversi da zero perché è controllata dal sistema operativo sottostante e può essere influenzata da molti fattori dinamici. Questi fattori includono la versione del sistema operativo, i modelli di attività e così via. Linux scambia proattivamente le chiavi inattive (raramente accessibili dai client) su disco come tecnica di ottimizzazione per liberare spazio di memoria per le chiavi utilizzate più di frequente.

Quando non c'è abbastanza memoria disponibile, lo scambio diventa problematico. Se si verifica questa circorstanza, il sistema inizia a spostare le pagine avanti e indietro tra il disco e la memoria. Nello specifico, uno SwapUsage inferiore a qualche centinaio di megabyte non influisce negativamente sulle prestazioni di Redis. Se SwapUsage è elevato e viene modificato attivamente, e sul cluster non c'è abbastanza memoria disponibile, le prestazioni possono essere penalizzate. Per maggiori informazioni, consulta:

• Perché riscontro un utilizzo elevato o crescente della memoria nel mio cluster ElastiCache?
• Perché si verifica lo scambio in ElastiCache?

Latenza causata dalla rete

Latenza di rete tra il client e il cluster ElastiCache

Per isolare la latenza di rete tra i nodi del client e del cluster, utilizza i test TCP traceroute o mtr dall'ambiente applicativo. In alternativa, utilizza uno strumento di debug come descritto nel documento AWS Systems Manager (documento SSM) AWSSupport-SetupIPMonitoringFromVPC per testare le connessioni dalla sottorete del client.

Il cluster sta raggiungendo i limiti di rete

Un nodo ElastiCache condivide gli stessi limiti di rete delle istanze di Amazon Elastic Compute Cloud (Amazon EC2) di tipo corrispondente. Ad esempio, il tipo di nodo cache.m6g.large ha gli stessi limiti di rete dell'istanza EC2 m6g.large. Per informazioni sulla verifica delle tre principali componenti delle prestazioni di rete relative alla capacità di larghezza di banda, delle prestazioni dei pacchetti al secondo (PPS) e delle connessioni monitorate, consulta Monitorare le prestazioni di rete per l'istanza EC2.

Per risolvere i problemi relativi ai limiti di rete sul nodo ElastiCache, consulta Risoluzione dei problemi - Limiti relativi alla rete.

Latenza dell'handshake TCP/SSL

I client si connettono ai cluster Redis utilizzando una connessione TCP. La creazione di una connessione TCP richiede alcuni millisecondi. I millisecondi aggiuntivi creano un ulteriore sovraccarico sulle operazioni Redis eseguite dall'applicazione e un'ulteriore pressione sulla CPU Redis. Quando il cluster utilizza la funzionalità di crittografia in transito di ElastiCache è importante controllare il volume delle nuove connessioni in considerazione dell'aumento in termini di tempo e utilizzo della CPU necessario per un handshake TLS. Un elevato volume di connessioni rapidamente aperte (NewConnections) e chiuse potrebbe influire sulle prestazioni del nodo. È possibile utilizzare il pool di connessioni per memorizzare nella cache le connessioni TCP stabilite in un pool. Le connessioni vengono quindi riutilizzate ogni volta che un nuovo client tenta di connettersi al cluster. È possibile implementare il pool di connessioni utilizzando la libreria client Redis (se supportata), con un framework disponibile per l'ambiente applicativo, o crearlo partendo da zero. Inoltre, è possibile utilizzare comandi aggregati come MSET/MGET come tecnica di ottimizzazione.

Sul nodo ElastiCache è presente un numero elevato di connessioni

È consigliabile monitorare le metriche di CloudWatch CurrConnections e NewConnections. Queste metriche monitorano il numero di connessioni TCP accettate da Redis. Un numero elevato di connessioni TCP potrebbe comportare il raggiungimento del limite maxclient pari a 65.000. Questo limite rappresenta il numero massimo di connessioni simultanee di cui è possibile disporre per ogni nodo. Se si raggiunge il limite di 65.000, si riceve l'errore ERR max number of clients reached (ERRORE numero massimo di client raggiunto). Se si aggiungono più connessioni oltre il limite del server Linux o del numero massimo di connessioni monitorate, le connessioni client aggiuntive generano errori di timeout della connessione. Per informazioni su come prevenire un numero elevato di connessioni, consulta Best practice: client Redis e Amazon ElastiCache per Redis.

Problemi di latenza lato client

La latenza e i timeout potrebbero derivare dal client stesso. Verificare l'utilizzo della memoria, della CPU e della rete sul lato client per determinare se una di queste risorse sta raggiungendo i propri limiti. Se l'applicazione è in esecuzione su un'istanza EC2, sfrutta le stesse metriche di CloudWatch esaminate in precedenza per verificare la presenza di colli di bottiglia. La latenza potrebbe verificarsi in un sistema operativo che non può essere monitorato a fondo dalle metriche predefinite di CloudWatch. Valuta se sia il caso di installare uno strumento di monitoraggio all'interno dell'istanza EC2, come atop o un agente CloudWatch.

Se i valori di configurazione del timeout impostati sul lato applicazione sono troppo piccoli, è possibile che si verifichino errori di timeout non necessari. Configura il timeout lato client in modo appropriato per concedere al server tempo a sufficienza per elaborare la richiesta e generare la risposta. Per maggiori informazioni, consulta Best practice: client Redis e Amazon ElastiCache per Redis.

L'errore di timeout ricevuto dall'applicazione rivela ulteriori dettagli. Questi dettagli includono se è coinvolto un nodo specifico, il nome del tipo di dati Redis che causa i timeout, il timestamp esatto in cui si è verificato il timeout e così via. Queste informazioni consentono di individuare la modalità con cui si verifica il problema. Utilizza queste informazioni per rispondere a domande come quelle di seguito:

• I timeout si verificano spesso in un determinato momento della giornata?
• Il timeout si è verificato in uno o più client?
• Il timeout si è verificato in uno o più nodi Redis?
• Il timeout si è verificato in uno o più cluster?

Utilizza questi modelli per esaminare il client o il nodo ElastiCache più probabile. Inoltre, per determinare se la latenza si è verificata sul lato client, sul nodo ElastiCache o sulla rete, è possibile utilizzare il log dell'applicazione e i log di flusso VPC.

Sincronizzazione di Redis

La sincronizzazione di Redis viene avviata durante gli eventi di backup, sostituzione e ridimensionamento. Si tratta di un carico di lavoro che può causare latenze per via dell'elevato volume di calcolo. Utilizza la metrica di CloudWatch SaveInProgress per determinare se la sincronizzazione è in corso. Per maggiori informazioni, consulta Come vengono implementati la sincronizzazione e il backup.

Eventi nel cluster ElastiCache

Controlla la sezione Eventi nella console ElastiCache per il periodo di tempo in cui hai osservato un aumento della latenza. Verifica la presenza di attività in background come la sostituzione dei nodi o gli eventi di failover che potrebbero essere causati dalla manutenzione gestita di ElastiCache e dagli aggiornamenti del servizio o da errori hardware imprevisti. Riceverai la notifica degli eventi programmati tramite la dashboard e l'e-mail del PHD.

Di seguito è riportato un esempio di registro eventi:

Finished recovery for cache nodes 0001
Recovering cache nodes 0001
Failover from master node <cluster_node> to replica node <cluster_node> completed

---

Informazioni correlate

Monitoraggio delle best practice con Amazon ElastiCache per Redis utilizzando Amazon CloudWatch

Diagnosi dei problemi di latenza - Redis

Risoluzione dei problemi di ElastiCache per Redis