Partilhar via

Resolver problemas de latência e tempos limite da Cache do Azure para Redis

  • Artigo

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 fases. A origem do tempo limite excedido ajuda a determinar a causa e a mitigação.

Esta seção discute a solução de problemas de latência e tempo limite que ocorrem ao se conectar ao Cache do Azure para Redis.

Nota

Várias das etapas de solução de problemas neste guia incluem instruções para executar comandos Redis e monitorar várias métricas de desempenho. Para obter mais informações e instruções, consulte os artigos na seção Informações adicionais.

Solução de problemas do lado do cliente

Aqui está a solução de problemas do lado do cliente.

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

Explosões de tráfego combinadas com configurações ruins ThreadPool podem 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” (introduza: UnresponsiveClients) para verificar se os anfitriões cliente conseguem lidar com picos de tráfego repentinos.

Monitore como suas ThreadPool estatísticas mudam ao longo do tempo usando um exemplo ThreadPoolLogger. 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árias questões que são interessantes:

  • Observe que na IOCP seção e na WORKER seção você tem um Busy valor que é maior do que o Min valor. Essa diferença significa que suas ThreadPool configurações precisam ser ajustadas.
  • Você também pode ver in: 64221. Esse valor indica que 64.221 bytes foram recebidos na camada de soquete do kernel do cliente, mas não foram lidos pelo aplicativo. Essa diferença normalmente significa que seu aplicativo (por exemplo, StackExchange.Redis) não está lendo dados da rede tão rapidamente quanto o servidor está enviando-os para você.

Você pode configurar suas ThreadPool Configurações para garantir que seu pool de threads seja dimensionado rapidamente em cenários de intermitência.

Grande valor de chave

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

Você pode usar o redis-cli --bigkeys comando para verificar se há chaves grandes no cache. Para obter mais informações, consulte redis-cli, a interface de linha de comando do Redis--Redis.

  • Aumente o tamanho da sua VM para obter maiores recursos de largura de banda
    • Mais largura de banda em sua VM cliente ou servidor pode reduzir os tempos de transferência de dados para respostas maiores.
    • Compare o uso 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 conexão que seu aplicativo usa.
    • Use uma abordagem round-robin para fazer solicitações em diferentes objetos de conexão

CPU elevada nos anfitriões do cliente

O alto uso da CPU do cliente indica que o sistema não consegue acompanhar o trabalho atribuído a ele. Mesmo que o cache tenha enviado a resposta rapidamente, o cliente pode não conseguir processar a resposta em tempo hábil. Nossa recomendação é manter a CPU do cliente menos 80%. Verifique a métrica "Erros" (Tipo: UnresponsiveClients) para determinar se os hosts do cliente podem processar respostas do servidor Redis a tempo.

Monitore o uso da CPU do cliente em todo o sistema usando métricas disponíveis no portal do Azure ou por meio de contadores de desempenho na máquina. Tenha cuidado para não monitorar a CPU do processo, porque um único processo pode ter baixo uso da CPU, mas a CPU em todo o sistema pode ser alta. Preste atenção aos picos no uso da CPU que correspondem aos tempos limites. CPU alta também pode causar valores altos in: XXX em TimeoutException mensagens de erro, conforme descrito na seção [Traffic burst].

Nota

StackExchange.Redis 1.1.603 e posterior inclui a métrica em mensagens de local-cpu TimeoutException erro. Verifique se você está usando a versão mais recente do pacote NuGet StackExchange.Redis. Bugs são corrigidos regularmente no código para torná-lo mais robusto aos tempos limites. Ter a versão mais recente é importante.

Para atenuar o alto uso da CPU de um cliente:

  • Investigue o que está causando picos de CPU.
  • Atualize 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

Dependendo da arquitetura das máquinas cliente, elas podem ter limitações na largura de banda de rede disponível. 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 levar a tempos limites.

Monitore como o uso da largura de banda muda ao longo do tempo usando um exemplo BandwidthLogger. Esse código pode não ser executado com êxito em alguns ambientes com permissões restritas (como sites do Azure).

Para atenuar, reduza o consumo de largura de banda da rede ou aumente o tamanho da VM do cliente para uma com mais capacidade de rede. Para obter mais informações, consulte Tamanho grande da solicitação ou resposta.

Configurações de TCP para aplicativos cliente baseados em Linux

Devido às configurações otimistas de TCP no Linux, os aplicativos cliente hospedados no Linux podem enfrentar problemas de conectividade. Para obter mais informações, consulte Configurações de TCP para aplicativos cliente hospedados no Linux

Tempo limite da nova tentativa RedisSessionStateProvider

Se você estiver usando RedisSessionStateProvidero , certifique-se de definir o tempo limite de repetição corretamente. O retryTimeoutInMilliseconds valor deve ser maior do que o operationTimeoutInMilliseconds valor. Caso contrário, não ocorrerão novas tentativas. No exemplo a seguir, retryTimeoutInMilliseconds é definido como 3000. Para obter mais informações, consulte ASP.NET Provedor de Estado de Sessão para Cache Redis do Azure e Como usar os parâmetros de configuração do Provedor de Estado de Sessão e do Provedor de Cache de Saída.

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

Solução de problemas do lado do servidor

Aqui está a soluçã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 uma solicitação, mas não recebe uma resposta quando o failover ocorre, pode obter uma exceção de tempo limite. Novas solicitações no objeto de conexão fechado recebem exceções de conexão até que a reconexão aconteça com êxito.

Para mais informações, consulte estas outras secções:

Para verificar se o Cache Redis do Azure teve um failover durante o tempo limite, verifique a métrica Erros. No menu Recurso do portal do Azure, selecione Métricas. Em seguida, crie um novo gráfico medindo a Errors métrica, dividido por ErrorType. Depois de criar este gráfico, você verá uma contagem para Failover.

Para obter mais informações sobre failovers, consulte Failover e aplicação de patches para o Cache do Azure para Redis.

Carga do servidor elevada

Alta carga do servidor significa que o servidor Redis é incapaz de acompanhar as solicitações, levando a tempos limites. O servidor pode ser lento a responder e incapaz de acompanhar as taxas de pedidos.

Monitore métricas como a carga do servidor. Preste atenção aos picos de Server Load uso que correspondem aos tempos limites. Crie alertas sobre métricas sobre a carga do servidor para ser notificado antecipadamente sobre possíveis impactos.

Existem várias alterações que pode fazer para mitigar uma carga de servidor elevada:

  • Investigue o que está causando alta carga do servidor, como comandos de longa execução, observados neste artigo, devido à alta pressão de memória.
  • Expanda para mais fragmentos para distribuir a carga em vários processos Redis ou aumente para um tamanho de cache maior com mais núcleos de CPU. Para obter mais informações, consulte Perguntas frequentes sobre planejamento do Cache do Azure para Redis.
  • Se sua carga de trabalho de produção em um cache C1 for afetada negativamente pela latência extra de algumas execuções de verificação de defesa interna, você poderá reduzir o efeito dimensionando para uma oferta de camada mais alta com vários núcleos de CPU, como C2.

Picos na carga do servidor

Em caches C0 e C1 , você pode ver picos curtos na carga do servidor não causados por um aumento nas solicitações algumas vezes ao dia enquanto a verificação do defensor interno está sendo executada nas VMs. Você vê uma latência maior para solicitações enquanto verificações internas do defensor acontecem nessas camadas. Os caches nas camadas C0 e C1 têm apenas um único núcleo para multitarefas, dividindo o trabalho de atender a verificação de defensores internos e solicitações Redis.

Elevada utilização da memória

Esta secção foi deslocada. Para obter mais informações, consulte Alto uso de memória.

Comandos de longa execução

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

Analise os comandos que você está emitindo para o servidor Redis para entender seus impactos no desempenho. Por exemplo, o comando KEYS é frequentemente usado sem saber que é uma operação O(N). Você pode evitar KEYS usando SCAN para reduzir picos de CPU.

Usando o comando SLOWLOG GET , você pode medir comandos caros que estão sendo executados no servidor.

Os clientes podem usar um console para executar esses comandos Redis para investigar comandos caros e de longa execução.

  • SLOWLOG é usado para ler e redefinir o log de consultas lentas do Redis. Ele pode ser usado para investigar comandos de longa execução no lado do cliente. O Redis Slow Log é um sistema para registrar consultas que excederam um tempo de execução especificado. O tempo de execução não inclui operações de E/S, como falar com o cliente, enviar a resposta e assim por diante, mas apenas o tempo necessário para realmente executar o comando. Os clientes podem medir/registrar comandos caros sendo executados em seu servidor Redis usando o SLOWLOG comando.
  • MONITOR é um comando de depuração que transmite 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 - comando retorna informações e estatísticas sobre o servidor em um formato que é simples de analisar por computadores e fácil de ler por humanos. Nesse caso, a seção CPU pode ser útil para investigar o uso da CPU. Uma carga de servidor de 100 (valor máximo) significa que o servidor Redis estava ocupado o tempo todo e nunca estava ocioso ao processar as solicitações.

Amostra 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 - retorna informações e estatísticas sobre o servidor de conexões de cliente em um formato legível principalmente por 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 serão enviados para o cliente tão rapidamente. O limite de tempo dos pedidos dos clientes pode ser excedido, uma vez que o servidor não consegue enviar os dados para o cliente com a 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. Você pode visualizar essas métricas no portal. Crie alertas sobre métricas, por exemplo, leitura de cache ou escrita de cache para ser notificado antecipadamente sobre potenciais impactos.

Para atenuar situações em que o uso da largura de banda da rede está próximo da capacidade máxima:

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

Exceções de tempo limite do StackExchange.Redis

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

Conteúdos relacionados