Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Neste artigo, discutimos como usar e monitorizar a carga de uma cache Azure Managed Redis.
Tamanhos de valor
O design da aplicação cliente determina se deve armazenar muitos valores pequenos ou um número mais reduzido de valores maiores. Da perspetiva do servidor Redis, os valores mais pequenos proporcionam um melhor desempenho. Recomendamos que mantenha o tamanho dos valores inferior a 100 KB.
Se o seu design exigir que armazene valores maiores no Azure Managed Redis, a carga do servidor será maior. Neste caso, poderá ter de utilizar um escalão de cache superior para garantir que a utilização da CPU não limita o throughput.
Mesmo que a cache tenha capacidade suficiente de CPU, valores maiores aumentam latências, por isso siga as orientações em Configurar tempos apropriados.
Evitar picos de ligações do cliente
Criar e fechar ligações é uma operação dispendiosa para o servidor Redis. Se a aplicação cliente criar ou fechar demasiadas ligações num curto período de tempo, poderá sobrecarregar o servidor Redis.
Se estiver a instanciar muitas instâncias de cliente para ligar imediatamente ao Redis, considere escalonar as novas criações de ligações para evitar um pico acentuado no número de clientes ligados.
Pressão da memória
Uma utilização elevada da memória no servidor aumenta a probabilidade de o sistema precisar de paginar dados para o disco, o que resulta em falhas de página e pode abrandar significativamente o sistema.
Evitar comandos de execução prolongada
O servidor Redis é um sistema de thread único. Comandos de execução longa podem causar latência ou tempos limite no lado do cliente porque o servidor não pode responder a outras solicitações enquanto está ocupado trabalhando em um comando de longa execução. Para mais informações, consulte Troubleshoot Azure Cache for Redis server-side issues.
Monitorizar a Carga do Servidor e a CPU
Adiciona monitorização na carga do servidor e CPU para garantir que recebes notificações quando algum deles estiver alto. A monitorização pode ajudar a compreender as restrições da aplicação. Em seguida, pode trabalhar proactivamente para mitigar os problemas. Recomendamos que tente manter a carga do servidor abaixo dos 80% para evitar efeitos de desempenho negativos. Uma carga sustentada do servidor superior a 80% pode levar a failovers não planejados. Atualmente, Azure Managed Redis expõe duas métricas em Insights em Monitorização no menu de Recursos à esquerda do portal: CPU e Server Load. Compreender o que é medido por cada métrica é importante ao monitorizá-las.
A métrica CPU (também conhecida como percentTempoDeProcessador) indica a utilização de CPU no nó que hospeda a cache. A métrica da CPU também inclui processos que não são estritamente processos do servidor Redis. A CPU inclui processos em segundo plano para anti-malware e outros. Como resultado, a métrica da CPU pode, por vezes, aumentar drasticamente e pode não ser um indicador perfeito da utilização da CPU para o servidor Redis.
A métrica de Carga do Servidor reflete a própria avaliação do servidor Redis sobre a carga global e é semelhante à métrica da CPU, mas ao nível de cluster.
Recomendações para SKUs Menores
Em SKUs Azure Managed Redis suportados por VMs 2-vCPU (B0–B5, X3 e M10), métricas baseadas em percentagem como Server Load e CPU são inerentemente mais sensíveis. Um único thread em segundo plano de curta duração pode consumir uma percentagem significativa do CPU total, fazendo com que as métricas pareçam elevadas mesmo quando a carga de trabalho real é leve. Como resultado, estas métricas podem sobrestimar a carga real em SKUs pequenos e podem não indicar saturação de carga de trabalho.
Ao rever métricas ao longo de períodos mais longos, como várias horas ou dias, recomendamos:
- Usar CPU em vez de Server Load , pois pode ser visualizado ao nível da instância, acrescentando mais granularidade
- Divisão por ID de instância das máquinas virtuais que apoiam a instância Azure Managed Redis
- Usar agregação média em vez de máxima para estes intervalos de tempo mais longos
Ainda pode usar agregação máxima em janelas de tempo curtas para detetar picos ou eventos breves (como aqueles que podem causar timeouts ou failovers), confiando na Média em janelas mais longas para análise de tendências em SKUs pequenos, especialmente ao usar CPU.
Teste de carga aumentada do servidor após o failover
Para SKUs standard e premium, cada cache é alojada em dois nós. Um balanceador de carga distribui as ligações de cliente para os dois nós. Quando ocorre uma manutenção planeada ou não planeada no nó primário, o nó fecha todas as ligações do cliente. Nestas situações, todas as ligações de clientes podem ser direcionadas para um único nó, o que faz com que a carga do servidor aumente no único nó restante. Recomendamos testar este cenário, reiniciando o nó primário e garantindo que um nó consegue lidar com todas as ligações dos clientes sem que a carga do servidor fique demasiado elevada.