Solucionar problemas de latência e tempos limite do Azure Managed Redis

Uma operação do cliente que não recebe uma resposta atempada pode resultar numa latência elevada ou exceção de tempo limite. Uma operação pode exceder o limite de tempo em várias etapas. A origem do timeout ajuda a determinar a causa e a mitigação.

Esta secção aborda a resolução de problemas de latência e tempos limite que ocorrem quando se liga ao Azure Managed Redis.

• Resolução de problemas do lado do cliente
  • Surto de tráfego e configuração do conjunto de threads
  • Tamanhos grandes de chaves-valor
  • CPU elevada nas máquinas do cliente
  • Limitação da largura de banda de rede nos anfitriões cliente
  • Definições de TCP para aplicações cliente baseadas no Linux
  • Tempo limite de reintento do RedisSessionStateProvider
• Resolução de problemas do lado do servidor
  • Manutenção de servidores
  • CPU alta
  • Picos na CPU
  • Elevada utilização da memória
  • Comandos de execução prolongada
  • Limitação da largura de banda de rede
  • Exceções de tempo limite do StackExchange.Redis

Resolução de problemas no lado do cliente

Segue-se a resolução de problemas do lado do cliente.

Configuração do conjunto de threads e pico de tráfego

As expansões de tráfego, combinadas com definições de ThreadPool inadequadas, pode resultar em atrasos no processamento de dados já enviados pelo servidor Redis, mas ainda não consumidos no lado do cliente. Verifique a métrica “Erros” (Tipo: UnresponsiveClients) para validar se os hosts cliente conseguem lidar com um aumento repentino no tráfego.

Você pode usar TimeoutException mensagens de StackExchange.Redis para investigar melhor:

    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)

Na exceção anterior, há vários problemas que são interessantes:

• Tenha em atenção que na secção IOCP e na secção WORKER tem um valor de Busy que é maior do que o valor de Min. Esta diferença significa que as suas definições ThreadPool precisam de ser ajustadas.
• Também pode consultar in: 64221. Este valor indica que foram recebidos 64 221 bytes na camada de socket do kernel do cliente, mas não foram lidos pela aplicação. Esta diferença significa normalmente que a sua aplicação (por exemplo, StackExchange.Redis) não está a ler dados da rede tão rapidamente como o servidor os está a enviar para si.

Pode configurar as suas ThreadPool Definições para garantir que o seu conjunto de threads é dimensionado rapidamente em cenários de pico.

Grande valor de chave

Para obter informações sobre como utilizar várias chaves e valores mais pequenos, consulte Considerar mais chaves e valores mais pequenos.

Pode utilizar o comando redis-cli --bigkeys para verificar se existem chaves grandes na sua cache. Para obter mais informações, consulte redis-cli, a interface da linha de comandos do Redis--Redis.

• Aumente o tamanho da sua VM para obter maiores recursos de largura de banda
  • Mais largura de banda na VM do cliente ou do servidor pode reduzir os tempos de transferência de dados para respostas maiores.
  • Compare a utilização atual da rede em ambas as máquinas com os limites do tamanho atual da VM. Mais largura de banda apenas no servidor ou apenas no cliente pode não ser suficiente.
• Aumente o número de objetos de ligação que a sua aplicação utiliza.
  • Utilize uma abordagem em “round-robin” (ordem circular) para realizar pedidos através de diferentes objetos de ligação.

CPU elevada nos hosts cliente

A utilização elevada da CPU do cliente indica que o sistema não consegue acompanhar o trabalho que lhe é atribuído. Apesar de a cache ter enviado a resposta rapidamente, o cliente poderá não conseguir processar a resposta atempadamente. A nossa recomendação é manter a CPU do cliente inferior a 80%. Verifique a métrica “Erros” (Tipo: UnresponsiveClients) para determinar se os anfitriões do cliente podem processar as respostas do servidor Redis atempadamente.

Monitorize a utilização da CPU em todo o sistema do cliente utilizando métricas disponíveis no portal do Azure ou através de contadores de desempenho na máquina. Tenha cuidado para não monitorizar a CPU do processo uma vez que um único processo pode ter uma utilização baixa da CPU mas a CPU de todo o sistema pode ser elevada. Esteja atento aos picos de utilização da CPU que correspondem aos timeouts. Um uso elevado da CPU também pode causar valores in: XXX elevados nas TimeoutException mensagens de erro, conforme descrito na seção [Pico de tráfego].

Para mitigar a utilização elevada da CPU de um cliente:

• Investigue o que está a causar picos da CPU.
• Atualize o seu cliente para um tamanho de VM maior com mais capacidade de CPU.

Limitação da largura de banda de rede nos anfitriões cliente

Consoante a arquitetura dos computadores cliente, estes poderão ter limitações na quantidade de largura de banda de rede que têm disponíveis. Se o cliente exceder a largura de banda disponível ao sobrecarregar a capacidade de rede, os dados não serão processados no lado do cliente à mesma velocidade com que o servidor os envia. Esta situação pode originar expirações do tempo limite.

Para mitigar, reduza o consumo da largura de banda da rede ou aumente o tamanho da VM cliente para uma com maior capacidade de rede. Para obter mais informações, consulte Tamanho grande de pedidos ou respostas.

Definições de TCP para aplicações cliente baseadas no Linux

Devido a definições de TCP otimistas no Linux, as aplicações cliente alojadas no Linux podem ter problemas de conectividade. Para obter mais informações, consulte Definições de TCP para aplicações cliente alojadas no Linux.

Tempo limite de nova tentativa do "RedisSessionStateProvider"

Se estiver a utilizar o RedisSessionStateProvider, certifique-se de que define o tempo limite de repetição corretamente. O valor de retryTimeoutInMilliseconds deve ser superior ao valor de operationTimeoutInMilliseconds. Caso contrário, não ocorrerão repetições. No exemplo seguinte, retryTimeoutInMilliseconds está definido como 3000. Para obter mais informações, Como usar os parâmetros de configuração do Provedor de Estado da Sessão e do Provedor de Cache de Saída.

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

Resolução de problemas do lado do servidor

Manutenção de servidores

A manutenção planeada ou não planeada pode provocar interrupções nas ligações do cliente. O número e o tipo de exceções depende da localização do pedido no caminho do código e de quando a cache fecha as respetivas ligações. Por exemplo, uma operação que envia um pedido mas não recebe uma resposta quando ocorre a ativação pós-falha pode obter uma exceção de tempo de espera. Os novos pedidos no objeto da ligação fechada recebem exceções de ligação até que o restabelecimento da ligação seja bem sucedido.

Para obter mais informações, veja Resiliência da ligação.

Uso Elevado de CPU

Alta CPU significa que o servidor Redis não consegue acompanhar as solicitações, levando a interrupções. O servidor pode ser lento a responder e incapaz de acompanhar as taxas de pedidos.

Monitore métricas como a CPU. Preste atenção aos picos de utilização CPU que correspondem com timeouts. Crie alertas sobre métricas na CPU para ser notificado antecipadamente sobre possíveis impactos.

Há várias alterações que você pode fazer para mitigar a alta CPU:

• Investigue o que está causando alta CPU, como comandos de longa execução, observados neste artigo, devido à alta pressão de memória.
• Escale horizontalmente para obter mais shards e distribuir a carga por vários processos Redis, ou escale verticalmente para um tamanho de cache maior com mais núcleos de CPU. Para obter mais informações, consulte Arquitetura Redis gerenciada do Azure.
• Se a sua carga de trabalho de produção num cache for afetada negativamente pela latência extra resultante de algumas análises internas de segurança, pode reduzir o efeito migrando o cache para um nível otimizado para computação ou ampliando para uma oferta superior com mais núcleos de CPU.

Picos na CPU

Em caches B0, B1, B3 e B5, pode haver picos curtos na CPU não causados por um aumento nas solicitações algumas vezes ao dia, enquanto a verificação do defender interno está sendo executada nos VMs. Vê uma latência mais elevada para os pedidos enquanto as análises internas do Defender são realizadas nestas camadas. Os caches nestas camadas têm apenas dois núcleos para multitarefa, dividindo o trabalho entre a execução de verificações de segurança interna e o atendimento a pedidos do Redis.

Elevada utilização da memória

Para obter mais informações, consulte Utilização elevada da memória.

Comandos de execução prolongada

Alguns comandos do Redis são mais dispendiosos de executar do que outros. A documentação dos comandos do Redis mostra a complexidade de tempo de cada comando. O processamento de comandos do Redis é de thread único. Qualquer comando que leve muito tempo a ser executado pode bloquear todos os outros que o seguem.

Analise os comandos que está a emitir para o seu servidor Redis para compreender os seus impactos no desempenho. Por exemplo, o comando KEYS é, muitas vezes, utilizado sem saber que é uma operação O(N). Pode evitar KEYS utilizando SCAN para reduzir os picos de uso da CPU.

Ao utilizar o comando SLOWLOG GET pode medir comandos dispendiosos que estão a ser executados no servidor.

Os clientes podem utilizar uma consola para executar estes comandos Redis para investigar comandos dispendiosos e de execução prolongada.

• O SLOWLOG é utilizado para ler e redefinir o registo de consultas lentas do Redis. Pode ser utilizado para investigar comandos que demoram a executar no lado do cliente. O Redis Slow Log é um sistema para registar as consultas que excederam um tempo de execução especificado. O tempo de execução não inclui operações de E/S tais como falar com o cliente, enviar a resposta, etc., mas apenas o tempo necessário para executar o comando efetivamente. Os clientes podem medir/registar comandos dispendiosos que estão a ser executados no seu servidor Redis utilizando o comando SLOWLOG.
• MONITOR é um comando de depuração que transmite de volta todos os comandos processados pelo servidor Redis. Pode ajudar a compreender o que está a acontecer à base de dados. Este comando é exigente e pode afetar negativamente o desempenho. Pode degradar o desempenho.
• INFO - o comando apresenta informações e estatísticas sobre o servidor num formato que é simples de analisar por computadores e fácil de ler por humanos. Neste caso, a secção CPU pode ser útil para investigar a utilização da CPU. Uma CPU de 100 (valor máximo) significa que o servidor Redis estava ocupado o tempo todo e nunca estava ocioso ao processar as solicitações.

Exemplo de saída:

# 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 - apresenta informações e estatísticas sobre o servidor de ligações do cliente num formato legível principalmente para humanos.

Limitação da largura de banda de rede

Diferentes tamanhos de cache têm diferentes capacidades de largura de banda da rede. Se o servidor exceder a largura de banda disponível, os dados não são enviados para o cliente tão rapidamente. Os pedidos dos clientes podem expirar porque o servidor não consegue enviar os dados para o cliente com rapidez suficiente.

É possível utilizar as métricas “Leitura da Cache” e “Escrita da Cache” para ver a utilização da largura de banda do lado do servidor. Pode-se ver estas métricas no portal. Crie alertas para métricas como leitura ou escrita de cache, para ser notificado antecipadamente sobre potenciais impactos.

Para mitigar situações nas quais a utilização da largura de banda da rede está próxima da capacidade máxima:

• Altere o comportamento da chamada do cliente para reduzir a demanda de rede.
• Dimensione para um tamanho de cache maior com mais capacidade de largura de banda de rede. Para obter mais informações, consulte Teste de desempenho com o Azure Managed Redis.

Exceções de tempo limite do StackExchange.Redis

Para obter informações mais específicas para abordar tempos limite ao utilizar o StackExchange.Redis, consulte Investigar exceções de tempo limite em StackExchange.Redis.

Conteúdo relacionado

• Solucionar problemas do lado do cliente do Azure Managed Redis
• Solucionar problemas do lado do servidor do Azure Managed Redis
• Testes de desempenho com o Azure Managed Redis
• Monitorar o Azure Managed Redis