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

  • Articolo

Un'operazione client che non riceve una risposta tempestiva può comportare un'eccezione di latenza o timeout elevati. Un'operazione potrebbe subire un timeout in varie fasi. La provenienza del timeout consente di determinare la causa e la mitigazione.

Questa sezione illustra la risoluzione dei problemi di latenza e timeout che si verificano durante la connessione a cache di Azure per Redis.

Nota

Diversi passaggi per la risoluzione dei problemi illustrati in questa guida includono istruzioni per eseguire comandi di Redis e monitorare svariate metriche delle prestazioni. Per altre informazioni e istruzioni, vedere gli articoli della sezione Informazioni aggiuntive .

Risoluzione dei problemi lato client

Viene ora illustrata la risoluzione dei problemi sul lato client.

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" (Tipo: UnresponsiveClients) per verificare se gli host client riescano a tenere il passo con un improvviso picco del traffico.

Monitorare il cambiamento delle statistiche ThreadPool nel corso del tempo usando un codice un ThreadPoolLogger di esempio. È possibile usare messaggi TimeoutException da StackExchange.Redis per approfondire le indagini:

    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)

Nell'eccezione precedente ci sono diversi problemi interessanti:

  • Si noti che nella sezione IOCP e nella sezione WORKER è presente un valore Busy maggiore del valore Min. Questa differenza significa che è necessario modificare le impostazioni di ThreadPool.
  • È anche possibile osservare in: 64221 Questo valore indica che sono stati ricevuti 64.221 byte al livello del socket del kernel del client, ma che non sono stati letti dall'applicazione. Questa differenza significa in genere che l'applicazione (ad esempio StackExchange.Redis) non legge i dati dalla rete con la stessa velocità con cui il server li invia.

È possibile configurare le impostazioni di ThreadPool in modo che il pool di thread consenta un rapido aumento delle risorse negli scenari di burst.

Valore di grandi dimensioni per la chiave

Per informazioni sull'uso di più chiavi e valori più piccoli, vedere Prendere in considerazione più chiavi e valori più piccoli.

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

  • Aumentare le dimensioni della macchina virtuale per ottenere capacità 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 entrambi i computer con i limiti delle dimensioni correnti della macchina virtuale. Una maggiore larghezza di banda solo sul server o solo 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

Utilizzo elevato della CPU negli host client

Un utilizzo elevato della CPU indica che il sistema non riesce a stare al passo con i compiti a esso assegnati. Anche se la cache ha inviato rapidamente la risposta, il client potrebbe non elaborare la risposta in modo tempestivo. È consigliabile mantenere la CPU del client inferiore all'80%. Controllare la metrica "Errori" (tipo: UnresponsiveClients) per determinare se gli host client riescono a elaborare le risposte dal server Redis in tempo.

Monitorare l'utilizzo della CPU a livello di sistema del client usando le metriche disponibili nel portale di Azure o tramite contatori delle prestazioni nel computer. Prestare attenzione a non monitorare la CPU del processo perché un singolo processo può avere un utilizzo della CPU basso, ma contemporaneamente l'utilizzo della CPU di sistema complessiva può essere elevato. Cercare nell'utilizzo della CPU i picchi corrispondenti ai timeout. Una CPU elevata può anche causare valori in: XXX elevati nei messaggi di errore TimeoutException, come descritto nella sezione [Burst del traffico].

Nota

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. I bug vengono corretti regolarmente nel codice in modo da rendere quest'ultimo più resistente ai timeout. Avere la versione più recente è importante.

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

  • Esaminare ciò che causa picchi di CPU.
  • Aggiornare il client a una dimensione di macchina virtuale maggiore con una capacità della CPU più elevata.

Limitazione della larghezza di banda di rete negli host client

A seconda dell'architettura dei computer client, possono esserci limitazioni relative alla quantità di larghezza di banda di rete disponibile. Se il client supera la larghezza di banda disponibile sovraccaricando la capacità di rete, i dati non verranno elaborati sul lato client con la stessa velocità con cui il server li invia. Questa situazione può causare timeout.

Monitorare il cambiamento dell'utilizzo della larghezza di banda nel corso del tempo usando un BandwidthLogger di esempio. Non è possibile eseguire correttamente questo codice in alcuni ambienti con autorizzazioni con restrizioni, come Siti Web di Azure.

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.

Impostazioni TCP per applicazioni client basate su Linux

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

Timeout dei tentativi RedisSessionStateProvider

Se si usa RedisSessionStateProvider, verificare di avere impostato correttamente il timeout per i tentativi. Il valore retryTimeoutInMilliseconds deve essere maggiore del valore operationTimeoutInMilliseconds. In caso contrario, non si verificano retry. Nell'esempio seguente retryTimeoutInMilliseconds è impostato su 3000. Per altre informazioni, vedere Provider di stato della sessione ASP.NET per Cache Redis di Azure e Come usare i parametri di configurazione del provider di stato della sessione e del provider della cache di output.

<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"
>

Risoluzione dei problemi lato server

Viene ora illustrata la risoluzione dei problemi lato server.

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. Ad esempio, un'operazione che invia una richiesta ma non riceve una risposta quando si verifica il failover potrebbe ricevere un'eccezione di timeout. Le nuove richieste sull'oggetto connessione chiusa ricevono eccezioni di connessione fino a quando la riconnessione non viene eseguita correttamente.

Per altre informazioni, vedere queste altre sezioni:

Per verificare se cache di Azure per Redis ha riscontrato un failover durante il timeout, controllare la metrica Errori. Nel menu Risorsa del portale di Azure selezionare Metriche. Creare quindi un nuovo grafico che misura la metrica Errors, divisa per ErrorType. Dopo aver creato questo grafico, viene visualizzato un conteggio per Failover.

Per altre informazioni sui failover, vedere Failover e applicazione di patch per Cache Redis di Azure.

Carico elevato del server

Un carico elevato del server significa che il server Redis non è in grado di mantenere il passo con le richieste, il che causa timeout. Il server potrebbe rispondere lentamente e non essere in grado di tenere il passo con le frequenze delle richieste.

Monitorare le metriche, ad esempio il carico del server. Cercare nell'utilizzo di Server Load i picchi corrispondenti ai timeout. Creare avvisi sul carico del server per ricevere notifiche tempestive sui potenziali impatti.

Esistono diverse modifiche che è possibile apportare per ridurre il carico elevato del server:

  • Esaminare ciò che causa un carico elevato del server, ad esempio comandi a esecuzione prolungata, indicati in questo articolo, a causa di un utilizzo elevato della memoria.
  • Aumentare il numero di partizioni per distribuire il carico tra più processi Redis o aumentare le dimensioni della cache con più core CPU. Per altre informazioni, vedere Domande frequenti sulla pianificazione di Cache Redis di Azure.
  • Se il carico di lavoro di produzione in una cache C1 è influenzato negativamente da una latenza aggiuntiva da alcune esecuzioni di analisi interne di Defender, è possibile ridurre l'effetto ridimensionando un'offerta di livello superiore con più core CPU, ad esempio C2.

Picchi di carico del server

Nelle cache di C0 e C1 potrebbero verificarsi brevi picchi di carico del server, non causati da un aumento delle richieste, un paio di volte al giorno mentre l'analisi interna di Defender è in esecuzione nelle macchine virtuali. Si noterà una latenza più elevata per le richieste mentre le analisi interne di Defender vengono eseguite su questi livelli. Le cache nei livelli C0 e C1 hanno un solo core per multitasking e dividono il lavoro di gestione delle richieste interne di Defender e Redis.

Uso elevato della memoria

Questa sezione è stata spostata. Per altre informazioni, vedere Utilizzo elevato della memoria.

Comandi a esecuzione prolungata

L'esecuzione di alcuni comandi di Redis risulta più costosa rispetto ad altri. La documentazione relativa ai comandi di Redis mostra la complessità temporale di ogni comando. L'elaborazione dei comandi Redis è a thread singolo. Qualsiasi comando la cui esecuzione richiede molto tempo può bloccare tutti gli altri comandi successivi.

Esaminare i comandi che si inviano al server Redis per comprendere gli effetti sulle prestazioni. Il comando KEYS, ad esempio, viene usato spesso senza sapere che si tratta di un'operazione O(N). È possibile evitare KEYS usando SCAN per ridurre i picchi di CPU.

L'uso del comando SLOWLOG GET consente di misurare l'esecuzione dei comandi costosi sul server.

I clienti possono usare una console per eseguire questi comandi Redis e analizzare così i comandi a esecuzione prolungata e costosi.

  • SLOWLOG viene usato per leggere e reimpostare il log delle query lente di Redis. Può essere usato per analizzare i comandi a esecuzione prolungata sul lato client. 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 conversazione con il client, l'invio della risposta e così via, ma solo il tempo necessario per eseguire effettivamente il comando. I clienti possono misurare o registrare comandi costosi eseguiti sul server Redis usando il comando SLOWLOG.
  • MONITOR è un comando di debug che trasmette ogni comando elaborato dal server Redis. Può essere utile per comprendere cosa accade al database. Questo comando richiede molte risorse e può influire negativamente sulle prestazioni. Può ridurre le prestazioni.
  • INFO: il comando restituisce informazioni e statistiche sul server in un formato semplice da analizzare dai computer e facilmente leggibile dagli utenti. In questo caso, la sezione CPU potrebbe essere utile per analizzare l'utilizzo della CPU. Un carico del server pari a 100 (valore massimo) indica che il server Redis è stato occupato tutto il tempo e che non è mai stato inattivo durante l'elaborazione delle richieste.

Esempio di output:

# 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
  • CLIENT LIST: restituisce informazioni e statistiche sul server connessioni client in un formato sostanzialmente leggibile dagli utenti.

Limitazione della 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 altrettanto 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.

Le metriche "Lettura della cache" e "Scrittura nella cache" possono essere usate per verificare la quantità di larghezza di banda lato server usata. È possibile visualizzare queste metriche nel portale. Creare avvisi sulle metriche, ad esempio la lettura della cache o la scrittura nella cache, per ricevere notifiche tempestive sui possibili effetti.

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

Eccezioni di timeout di StackExchange.Redis

Per informazioni più specifiche su come risolvere i timeout quando si usa StackExchange.Redis, vedere Analisi delle eccezioni di timeout in StackExchange.Redis.

Contenuto correlato