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

Ecco la risoluzione dei problemi sul lato client.

Configurazione del pool di thread e del burst del traffico

I picchi di traffico combinati con impostazioni scarse ThreadPool possono comportare 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 modo in cui le ThreadPool statistiche cambiano nel tempo usando un esempio ThreadPoolLogger. È possibile usare TimeoutException i messaggi di 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 sono presenti 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 le ThreadPool impostazioni devono essere modificate.
  • È anche possibile osservare in: 64221 Questo valore indica che sono stati ricevuti 64.221 byte al livello del socket del kernel del client, ma non sono stati 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.

È possibile configurare il ThreadPool Impostazioni per assicurarsi che il pool di thread venga ridimensionato rapidamente in scenari di burst.

Valore della chiave di grandi dimensioni

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

È possibile usare il redis-cli --bigkeys comando 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 funzionalità di larghezza di banda più elevate
    • Una maggiore larghezza di banda nella macchina virtuale client o server potrebbe ridurre i tempi di trasferimento dei dati per risposte di dimensioni maggiori.
    • 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

Utilizzo elevato della CPU del client indica che il sistema non riesce a tenere il passo con il lavoro assegnato. Anche se la cache ha inviato rapidamente la risposta, il client potrebbe non riuscire a elaborare la risposta in modo tempestivo. È consigliabile mantenere la CPU del client inferiore all'80%. Controllare la metrica "Errors" (Tipo: UnresponsiveClients) per determinare se gli host client possono 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 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, 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 per renderli più affidabili per i 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 maggiore capacità della CPU.

Limitazione della larghezza di banda di rete negli host client

A seconda dell'architettura dei computer client, potrebbero avere limitazioni sulla 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 la modifica dell'utilizzo della larghezza di banda nel tempo usando un esempio BandwidthLogger. Questo codice potrebbe non essere eseguito correttamente in alcuni ambienti con autorizzazioni limitate , ad esempio siti Web di Azure.

Per ridurre il consumo di larghezza di banda di rete o aumentare le dimensioni della macchina virtuale client a una con più capacità di rete. Per altre informazioni, vedere Dimensioni di richiesta o risposta 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 le applicazioni client ospitate in Linux

Timeout dei tentativi RedisSessionStateProvider

Se si usa RedisSessionStateProvider, assicurarsi di impostare correttamente il timeout dei tentativi. Il retryTimeoutInMilliseconds valore deve essere maggiore del operationTimeoutInMilliseconds valore . In caso contrario, non si verificano tentativi. Nell'esempio retryTimeoutInMilliseconds seguente viene 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

Ecco 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 ottenere 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 il cache di Azure per Redis ha avuto un failover durante l'esecuzione dei timeout, controllare gli errori della metrica. Nel menu Risorsa del portale di Azure selezionare Metriche. Creare quindi un nuovo grafico che misura la Errors metrica, suddivisa 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 di Azure per Redis.

Carico elevato del server

Carico elevato del server indica che il server Redis non è in grado di tenere il passo con le richieste, causando 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. Controllare i picchi di Server Load utilizzo che corrispondono ai timeout. Creare avvisi sulle metriche sul carico del server per ricevere una notifica anticipata 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 i comandi a esecuzione prolungata, annotati in questo articolo, a causa di un utilizzo elevato della memoria.
  • Aumentare il numero di istanze a più partizioni per distribuire il carico tra più processi Redis o aumentare le dimensioni della cache con più core CPU. Per altre informazioni, vedere cache di Azure per Redis domande frequenti sulla pianificazione.
  • Se il carico di lavoro di produzione in una cache C1 è influenzato negativamente dalla latenza aggiuntiva dall'analisi di virus, è possibile ridurre l'effetto per pagare un'offerta di livello superiore con più core CPU, ad esempio C2.

Picchi di carico del server

Nelle cache C0 e C1 potrebbero verificarsi brevi picchi di carico del server non causati da un aumento delle richieste un paio di volte al giorno durante l'esecuzione dell'analisi dei virus nelle macchine virtuali. Si noterà una latenza più elevata per le richieste durante l'analisi di virus in questi livelli. Le cache nei livelli C0 e C1 hanno un solo core a multitasking, dividendo il lavoro di gestione delle richieste di virus 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 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 tutti gli altri che vengono dopo di esso.

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 O(N). È possibile evitare CHIAVI usando SCAN per ridurre i picchi di CPU.

Usando il comando SLOWLOG GET , è possibile misurare i comandi costosi eseguiti sul server.

I clienti possono usare una console per eseguire questi comandi Redis per analizzare 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 SLOWLOG comando .
  • MONITOR è un comando di debug che trasmette tutti i comandi elaborati dal server Redis. Può essere utile per comprendere cosa accade al database. Questo comando richiede 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 da computer e facile da leggere da parte degli esseri umani. 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 era occupato tutto il tempo e non era mai 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
  • ELENCO CLIENT: restituisce informazioni e statistiche sul server connessioni client in un formato prevalentemente leggibile.

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

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 per risolvere i timeout quando si usa StackExchange.Redis, vedere Analisi delle eccezioni di timeout in StackExchange.Redis.

Contenuto correlato