Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In questo articolo viene illustrato come usare e monitorare il carico di una cache Redis gestita di Azure.
Dimensioni dei valori
La progettazione dell'applicazione client determina se archiviare molti valori piccoli o un numero minore di valori più grandi. Dal punto di vista del server Redis, valori più piccoli offrono prestazioni migliori. È consigliabile mantenere le dimensioni del valore inferiori a 100 kB.
Se la progettazione richiede di archiviare valori più grandi nella Azure Redis gestita, il carico del server sarà superiore. In questo caso, potrebbe essere necessario usare un livello di cache superiore per garantire che l'utilizzo della CPU non limiti la velocità effettiva.
Anche se la cache ha capacità cpu sufficiente, i valori più grandi aumentano le latenze, quindi seguire le indicazioni in Configurare i timeout appropriati.
Evitare picchi di connessione client
La creazione e la chiusura delle connessioni è un'operazione costosa per il server Redis. Se l'applicazione client crea o chiude un numero eccessivo di connessioni in un periodo di tempo ridotto, il server Redis potrebbe sovraccaricarsi.
Se si istanziano molte istanze client con connessione simultanea a Redis, è consigliabile dilatare le nuove creazioni di connessione per evitare un picco ripido nel numero di client connessi.
Pressione della memoria
Un elevato utilizzo della memoria sul server rende più probabile che il sistema debba spostare i dati su disco, causando interruzioni di pagina che possono rallentare significativamente il sistema.
Evitare comandi a esecuzione prolungata
Il server Redis è un sistema a thread singolo. I comandi a esecuzione prolungata possono causare latenza o timeout sul lato client perché il server non può rispondere ad altre richieste mentre è occupato a gestire un comando a esecuzione prolungata. Per altre informazioni, vedere Risolvere i problemi di cache di Azure per Redis lato server.
Monitorare il carico del server e la CPU
Aggiungere il monitoraggio sul carico del server e sulla CPU per assicurarsi di ricevere notifiche quando una di esse è elevata. Il monitoraggio consente di comprendere i vincoli dell'applicazione. È quindi possibile lavorare in modo proattivo per attenuare i problemi. È consigliabile mantenere il carico del server inferiore all'80% per evitare effetti negativi sulle prestazioni. Il carico del server prolungato oltre l'80% può causare failover non pianificati. Attualmente, Azure Managed Redis espone due metriche in Insights in Monitoring nel menu Risorsa a sinistra del portale: CPU e Server Load. Comprendere cosa viene misurato in base a ogni metrica è importante quando vengono monitorati.
La metrica CPU (ad esempio percentProcessorTime) indica l'utilizzo della CPU per il nodo che ospita la cache. La metrica CPU include anche processi che non sono strettamente legati al server Redis. La CPU include processi in background per antimalware e altri. Di conseguenza, la metrica CPU può talvolta aumentare e potrebbe non essere un indicatore perfetto dell'utilizzo della CPU per il server Redis.
La metrica Carico server riflette la valutazione del carico complessivo del server Redis ed è simile alla metrica della CPU, ma a livello di cluster.
Raccomandazioni per SKU più piccoli
Negli SKU Redis gestiti su Azure supportati da macchine virtuali con 2 vCPU (B0-B5, X3 e M10), le metriche in percentuale come Server Load e CPU sono intrinsecamente più sensibili. Un singolo thread in background di breve durata può utilizzare una percentuale significativa della CPU totale, causando la visualizzazione delle metriche elevate anche quando il carico di lavoro effettivo è leggero. Di conseguenza, queste metriche possono sovrastimare il carico effettivo su SKU di piccole dimensioni e potrebbero non indicare la saturazione del carico di lavoro.
Quando si esaminano le metriche in periodi di tempo più lunghi, ad esempio diverse ore o giorni, è consigliabile:
- Uso della CPU anziché del carico del server perché può essere visualizzato a livello di istanza aggiungendo maggiore granularità
- Suddivisione in base all'ID istanza delle macchine virtuali che supportano l'istanza di Redis gestita da Azure.
- Uso dell'aggregazione Media anziché massimo per questi intervalli di tempo più lunghi
È comunque possibile usare l'aggregazione massima in brevi intervalli di tempo per rilevare brevi picchi o eventi (ad esempio quelli che potrebbero causare timeout o failover), mentre si basa su Media su finestre più lunghe per l'analisi delle tendenze su SKU di piccole dimensioni, in particolare quando si usa la CPU.
Testare l'aumento del carico del server dopo il failover
Per gli SKU standard e premium, ogni cache è ospitata in due nodi. Un servizio di bilanciamento del carico distribuisce le connessioni client ai due nodi. Quando si verifica una manutenzione pianificata o non pianificata nel nodo primario, il nodo chiude tutte le connessioni client. In tali situazioni, tutte le connessioni client potrebbero raggiungere un singolo nodo, causando l'aumento del carico del server sul nodo rimanente. È consigliabile testare questo scenario riavviando il nodo primario e assicurandosi che un nodo possa gestire tutte le connessioni client senza che il carico del server sia troppo elevato.