Condividi tramite

Risolvere i problemi relativi a latenza e timeout di cache di Azure per Redis

  • Si applica a: ✅ Azure Cache for Redis

Un'operazione client di Cache Redis di Azure che non riceve una risposta tempestiva può causare una latenza elevata o un'eccezione di timeout. Questo articolo illustra come risolvere i problemi comuni che possono causare una latenza elevata e timeout.

Un'operazione potrebbe riscontrare problemi o interruzioni in varie fasi. L'origine del problema consente di determinare la causa e la mitigazione. Questo articolo è suddiviso in problemi lato client e lato server.

Problemi lato client

Problemi lato server

Risoluzione dei problemi lato client

I problemi lato client seguenti possono influire sulla latenza e sulle prestazioni e causare timeout.

Connessioni client elevate

Le richieste client di connessioni client oltre il valore massimo per la cache possono non riuscire. Le connessioni client elevate possono anche causare un carico elevato del server durante l'elaborazione di tentativi di riconnessione ripetuti.

Le connessioni client elevate potrebbero indicare una perdita di connessione nel codice client. Le connessioni potrebbero non essere riutilizzate o chiuse correttamente. Esaminare il codice client per l'uso della connessione.

Se le connessioni elevate sono tutte connessioni client legittime e necessarie, potrebbe essere necessario aggiornare la cache a una dimensione con un limite di connessione superiore. Controllare se la metrica Max aggregate for Connected Clients è vicina o superiore al numero massimo di connessioni consentite per le dimensioni della cache. Per ulteriori informazioni sul dimensionamento per connessioni client, vedere le prestazioni della cache di Azure per Redis.

Utilizzo elevato della CPU negli host client

Utilizzo elevato della CPU del client indica che il sistema non è in grado di tenere il passo con il lavoro assegnato. Anche se la cache invia la risposta rapidamente, il client potrebbe non riuscire a elaborare la risposta in modo sufficientemente veloce. È consigliabile mantenere la CPU del client a meno di 80%.

Per ridurre l'utilizzo elevato della CPU di un client:

  • Esaminare la causa dei picchi di CPU.
  • Aggiornare il client a una macchina virtuale (VM) di dimensioni maggiori con una maggiore capacità della CPU.

Monitorare l'utilizzo della CPU a livello di sistema del client usando le metriche disponibili nel portale di Azure o tramite contatori delle prestazioni nella macchina virtuale. Controllare la metrica Errors (Type: UnresponsiveClients) per determinare se gli host client possono elaborare le risposte dal server Redis in tempo.

Prestare attenzione a non monitorare la CPU del processo, perché un singolo processo può avere un utilizzo ridotto della CPU, ma la CPU a livello di sistema può essere elevata. Cercare nell'utilizzo della CPU i picchi corrispondenti ai timeout. Una CPU elevata può anche causare valori elevati in: XXX nei timeoutException messaggi di errore. Per un esempio, vedere la sezione Configurazione dei burst di traffico e del thread pool.

StackExchange.Redis 1.1.603 e versioni successive includono la metrica local-cpu nei messaggi di errore timeoutException. Assicurarsi di usare la versione più recente del pacchetto NuGet StackExchange.Redis, perché i bug vengono corretti regolarmente per rendere il codice più resistente ai timeout. Per altre informazioni, vedere Analisi delle timeout eccezioni in StackExchange.Redis.

Valori di chiave di grandi dimensioni

È possibile usare il comando redis-cli --bigkeys per verificare la presenza di chiavi di grandi dimensioni nella cache. Per altre informazioni su redis-cli, l'interfaccia della riga di comando di Redis, vedere Interfaccia della riga di comando di Redis.

Per attenuare il problema:

  • Aumentare le dimensioni della macchina virtuale per ottenere funzionalità di larghezza di banda più elevate. Una maggiore larghezza di banda nella macchina virtuale client o server può ridurre i tempi di trasferimento dei dati per risposte più grandi. Confrontare l'utilizzo di rete corrente in entrambe le macchine virtuali con i limiti delle dimensioni correnti della macchina virtuale. Una maggiore larghezza di banda solo sul server o sul client potrebbe non essere sufficiente.

  • Aumentare il numero di oggetti di connessione usati dall'applicazione. Usare un approccio round robin per effettuare richieste su oggetti di connessione diversi. Per informazioni sull'uso di più chiavi e valori più piccoli, vedere Prendere in considerazione più chiavi e valori più piccoli.

Utilizzo elevato della memoria nel client Redis

La pressione della memoria sul client può causare problemi di prestazioni che ritardano l'elaborazione delle risposte della cache. Quando si verifica pressione sulla memoria, il sistema potrebbe spostare i dati su disco. Questo errore di pagina causa un rallentamento significativo del sistema.

Per rilevare la pressione della memoria sul client:

  • Monitorare l'utilizzo della memoria nella macchina virtuale per assicurarsi che non superi la memoria disponibile.
  • Monitorare il contatore delle prestazioni del cliente Page Faults/Sec. Durante il normale funzionamento, la maggior parte dei sistemi presenta alcuni errori di pagina. I picchi di errori di pagina corrispondenti ai timeout della richiesta possono indicare un utilizzo elevato di memoria.

Per ridurre l'utilizzo elevato della memoria sul client:

  • Esaminare i modelli di utilizzo della memoria per ridurre il consumo di memoria nel client.
  • Aggiornare la macchina virtuale client a dimensioni maggiori con maggiore memoria.

Limitazione della larghezza di banda di rete negli host client

A seconda dell'architettura, i computer client potrebbero avere limitazioni sulla disponibilità della larghezza di banda di rete. Se il client supera la larghezza di banda disponibile sovraccaricando la capacità di rete, i dati non vengono elaborati sul lato client appena il server lo invia. Questa situazione può causare timeout.

Per attenuare il problema, ridurre il consumo di larghezza di banda di rete o aumentare le dimensioni della macchina virtuale client scegliendo dimensioni con più capacità di rete. Per altre informazioni, vedere Richieste o risposte di grandi dimensioni.

RedisSessionStateProvider retryTimeout

Se si usa RedisSessionStateProvider, assicurarsi di impostare correttamente retryTimeout . Il valore retryTimeoutInMilliseconds deve essere maggiore del valore operationTimeoutInMilliseconds. In caso contrario, non si verificano retry.

Nell'esempio seguente viene retryTimeoutInMilliseconds impostato su 3000.

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

Per altre informazioni, vedere:

Impostazioni TCP per applicazioni client basate su Linux

Le applicazioni client ospitate in Linux potrebbero riscontrare problemi di connettività a causa delle impostazioni TCP ottimistiche in Linux. Per altre informazioni, vedere Impostazioni TCP per le applicazioni client ospitate in Linux.

Configurazione del pool di thread e del burst del traffico

I burst di traffico combinati con impostazioni ThreadPool insufficienti possono causare ritardi nell'elaborazione dei dati già inviati dal server Redis, ma non ancora utilizzati sul lato client. Controllare la metrica Errors (Type: UnresponsiveClients) per verificare se gli host client possono tenere il passo con picchi improvvisi di traffico. È possibile configurare le impostazioni di ThreadPool per assicurarsi che il pool di thread venga ridimensionato rapidamente in scenari burst.

È possibile usare timeoutException i messaggi di StackExchange.Redis per approfondire l'analisi.

    System.timeoutException: timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
    IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

L'eccezione precedente illustra diversi problemi.

  • Nella sezione IOCP e nella sezione WORKER, il valore Busy è maggiore del valore Min, il che significa che le impostazioni ThreadPool devono essere modificate.
  • Il valore in: 64221 indica che sono stati ricevuti 64.221 byte al livello del socket del kernel del client, ma non letti dall'applicazione. Questa differenza significa in genere che l'applicazione, ad esempio StackExchange.Redis, non legge i dati dalla rete appena il server lo invia.

StackExchange.Redis 1.1.603 e versioni successive includono la metrica local-cpu nei messaggi di errore timeoutException. Assicurarsi di usare la versione più recente del pacchetto NuGet StackExchange.Redis, perché i bug vengono corretti regolarmente per rendere il codice più resistente ai timeout. Per altre informazioni, vedere Analisi delle eccezioni di timeout in StackExchange.Redis.

Risoluzione dei problemi lato server

I problemi sul lato server seguenti possono influire sulle prestazioni e causare timeout.

Uso elevato della memoria

La pressione della memoria sul server può causare vari problemi di prestazioni che ritardano l'elaborazione delle richieste. Quando si verifica pressione sulla memoria, il sistema sposta i dati su disco, causando un rallentamento significativo del sistema.

Alcune possibili cause di utilizzo elevato della memoria sono che la cache viene riempita di dati fino alla capacità massima o che il server Redis presenta una frammentazione elevata della memoria.

La frammentazione è probabilmente quando un modello di carico archivia i dati con variazioni di dimensioni elevate, ad esempio quando i dati vengono distribuiti tra dimensioni di 1 KB e 1 MB. Quando una chiave da 1 KB viene eliminata dalla memoria esistente, una chiave da 1 MB non può rientrare nello spazio, causando la frammentazione. Analogamente, se viene eliminata una chiave da 1 MB, una chiave da 1,5 MB aggiunta non può rientrare nella memoria recuperata esistente. Questa memoria libera inutilizzata comporta la frammentazione.

Se una cache è frammentata ed è in esecuzione con un utilizzo elevato della memoria, il sistema esegue un failover per tentare di recuperare la memoria RSS (Resident Set Size). Redis espone due statistiche, used_memory e used_memory_rss, tramite il comando INFO, che consente di identificare questo problema. È anche possibile visualizzare queste metriche nel portale di Azure.

Se il valore used_memory_rss è superiore a 1,5 volte la metrica used_memory, è presente una frammentazione in memoria. La frammentazione può causare problemi quando:

  • L'utilizzo della memoria è vicino al limite massimo di memoria per la cache.
  • La used_memory_rss metrica è superiore al limite massimo di memoria, causando potenzialmente errori di pagina in memoria.

È possibile eseguire diverse azioni per mantenere integro l'utilizzo della memoria.

Per altre raccomandazioni sulla gestione della memoria, vedere Procedure consigliate per la gestione della memoria.

Carico elevato del server

Il carico del server elevato indica che il server Redis è occupato e non è in grado di tenere il passo con le richieste, causando timeout o risposte lente. Per ridurre il carico elevato del server, esaminare prima di tutto la causa, ad esempio i comandi a esecuzione prolungata a causa di un utilizzo elevato della memoria.

È possibile monitorare le metriche , ad esempio il caricamento del server dal portale di Azure. Per controllare la metrica Carico server, selezionare Informazioni dettagliate in Monitoraggio dal menu di spostamento a sinistra nella pagina della cache e visualizzare il grafico Carico server. In alternativa, selezionare Metriche in Monitoraggio nel menu di spostamento a sinistra e quindi selezionare Carico server in Metriche.

Controllare i picchi di utilizzo del carico del server che corrispondono ai timeout. Creare avvisi sulle metriche di caricamento del server per ricevere una notifica anticipata sui potenziali impatti.

Picchi di carico del server

Nelle cache C0 e C1 è possibile che si verifichino brevi picchi di carico del server non causati da un aumento delle richieste, mentre l'analisi interna di Defender è in esecuzione nelle macchine virtuali. In questi livelli viene visualizzata una latenza più elevata per le richieste mentre si verificano analisi interne di Defender.

Le cache nei livelli C0 e C1 hanno un solo core per il multitasking, dividendo il lavoro di servire la scansione interna di Defender e gestire le richieste di Redis. Se un'eventuale latenza aggiuntiva derivante dalle scansioni interne di Defender influisce negativamente sul carico di lavoro di produzione in una cache C1, è possibile passare a un'offerta di livello superiore con più core della CPU, ad esempio C2. Per altre informazioni, vedere Scelta del livello corretto.

Per altre informazioni sulle modifiche rapide nel numero di connessioni client, vedere Evitare picchi di connessione client.

Scalabilità

È possibile aumentare il numero di istanze in più partizioni per distribuire il carico tra più processi Redis o aumentare le dimensioni della cache con più core CPU. Le operazioni di ridimensionamento sono a elevato utilizzo di CPU e memoria, perché possono comportare lo spostamento dei dati nei nodi e la modifica della topologia del cluster. Per ulteriori informazioni, vedere FAQ sulla pianificazione di Azure Cache per Redis e Scalabilità.

Comandi a esecuzione prolungata

L'esecuzione di alcuni comandi di Redis risulta più costosa rispetto ad altri. La documentazione dei comandi Redis mostra la complessità temporale di ogni comando. L'elaborazione dei comandi Redis è a thread singolo. Qualsiasi comando che richiede molto tempo per l'esecuzione può bloccare altri che lo seguono.

Esaminare i comandi che si eseguono al server Redis per comprendere gli effetti sulle prestazioni. Ad esempio, il comando KEYS viene spesso usato senza sapere che si tratta di un'operazione big O Notation (O(N)). Per ridurre i picchi di CPU, è possibile evitare KEYS utilizzando SCAN.

È possibile eseguire i comandi Redis seguenti in una console per esaminare i comandi a esecuzione prolungata e costosi.

  • ELENCO CLIENT

    Il comando CLIENT LIST restituisce informazioni e statistiche sul server delle connessioni client in un formato principalmente leggibile dall'uomo.

  • INFORMAZIONI

    Il INFO comando restituisce informazioni e statistiche sul server in un formato semplice per consentire ai computer di analizzare e semplificare la lettura degli utenti. La CPU sezione può essere utile per analizzare l'utilizzo della CPU. Un server_load valore ( 100 valore massimo) indica che il server Redis era occupato tutto il tempo e non era mai inattivo durante l'elaborazione delle richieste.

    L'esempio seguente mostra un output del INFO comando :

    # CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1

  • MONITOR

    MONITOR è un comando di debug che trasmette ogni comando elaborato dal server Redis. MONITOR consente di comprendere cosa sta accadendo al database. Questo comando richiede e può influire negativamente sulle prestazioni.

  • SLOWLOG

    Redis Slow Log è un sistema per registrare le query che hanno superato un periodo di esecuzione specificato. Il tempo di esecuzione non include operazioni di I/O come la comunicazione con il client o l'invio della risposta, ma solo il tempo necessario per eseguire effettivamente il comando.

    Il comando SLOWLOG legge e reimposta il log delle query lente di Redis e può essere usato anche per analizzare i comandi a esecuzione prolungata sul lato client. È possibile monitorare e registrare comandi costosi eseguiti sul server Redis usando SLOWLOG GET.

Limitazioni relative alla larghezza di banda della rete

Dimensioni di cache diverse hanno capacità diverse per la larghezza di banda di rete. Se il server supera la larghezza di banda disponibile, i dati non vengono inviati al client più rapidamente. È possibile che si verifichi il timeout delle richieste dei client perché il server non può eseguire il push dei dati al client in modo sufficientemente rapido.

È possibile monitorare le metriche , ad esempio lettura cache e scrittura nella cache nel portale di Azure, per verificare la quantità di larghezza di banda lato server usata. Creare avvisi su queste metriche per ricevere una notifica anticipata sui potenziali impatti.

Per attenuare le situazioni in cui l'utilizzo della larghezza di banda di rete è vicino alla capacità massima:

Manutenzione del server

La manutenzione pianificata o non pianificata può causare interruzioni alle connessioni client. Il numero e il tipo di eccezioni dipendono dalla posizione della richiesta nel percorso del codice e dal momento in cui la cache chiude le relative connessioni.

Se la cache Redis di Azure subisce un failover, tutte le connessioni client dal nodo inattivo vengono trasferite al nodo ancora in esecuzione. Il carico del server potrebbe aumentare a causa delle connessioni aumentate. È possibile provare a riavviare le applicazioni client in modo che tutte le connessioni client vengano ricreate e ridistribuite tra i due nodi.

Un'operazione che invia una richiesta ma non riceve una risposta quando si verifica il failover potrebbe ottenere un'eccezione timeout . Le nuove richieste sull'oggetto connessione chiusa ricevono eccezioni di connessione fino a quando la riconnessione non viene eseguita correttamente.

Per verificare se la cache Redis di Azure ha avuto un failover durante il momento timeout in cui si sono verificate le eccezioni, controllare la metrica Errori . Nella pagina del portale di Azure per la cache selezionare Metriche in Monitoraggio nel menu di spostamento a sinistra. Creare quindi un nuovo grafico che misura la metrica Errori , suddivisa per ErrorType. Dopo aver creato questo grafico, viene visualizzato un conteggio per Failover. Per ulteriori informazioni sui failover, consultare Gestione dei failover e degli aggiornamenti per Azure Cache per Redis.

Per altre informazioni sulla mitigazione dei problemi dovuti alla manutenzione del server, vedere gli articoli seguenti:

Contenuto correlato