Compartilhar via

Solucionar problemas de latência e tempo limite do Cache do Azure para Redis

  • Artigo

Uma operação de cliente que não recebe uma resposta em tempo pode resultar em uma exceção de alta latência ou tempo limite atingido. Uma operação pode atingir o tempo limite em vários estágios. A origem do tempo limite ajuda a determinar a causa e a mitigação.

Esta seção aborda a solução de problemas de latência e tempo limite que ocorrem durante a conexão com o Cache do Azure para Redis.

Observação

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

Solução de problemas do lado do cliente

Veja a solução de problemas do lado do cliente a seguir.

Configuração do pool de threads e de intermitência de tráfego

A intermitência de tráfego, combinada com configurações de ThreadPool ruins, podem resultar em atrasos no processamento de dados que já foram enviados pelo servidor Redis, mas ainda não foram consumidos no lado do cliente. Verifique a métrica "Erros" (tipo: UnresponsiveClients) para validar se os hosts cliente podem suportar um pico repentino no tráfego.

Monitore como as estatísticas ThreadPool mudam ao longo do tempo usando um exemploThreadPoolLogger. Você pode usar mensagens TimeoutException do StackExchange.Redis para investigar ainda mais:

    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 interessantes:

  • Observe que, na seção IOCP e na seção WORKER, você tem um valor Busy que é maior que o valor Min. Essa diferença significa que as configurações ThreadPool precisam de ajuste.
  • 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. Normalmente, essa diferença significa que o aplicativo (por exemplo, StackExchange.Redis) não está lendo dados da rede na velocidade em que o servidor os está enviando para você.

Você pode configurar as Definições ThreadPool para confirmar que o pool de threads seja escalado verticalmente com rapidez em cenários de intermitência.

Valor de chave grande

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

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

  • Aumentar o tamanho da VM para capacidade de largura de banda mais alta
    • Mais largura de banda na VM do cliente ou do servidor pode reduzir os tempos de transferência de dados para respostas maiores.
    • Compare o uso de rede atual em ambos os computadores com os limites do tamanho atual da VM. Mais largura de banda somente no servidor ou somente no cliente pode não ser suficiente.
  • Aumentar o número de objetos de conexão que o aplicativo usa.
    • Usar uma abordagem Round Robin para fazer solicitações em diferentes objetos de conexão

Uso elevado de CPU em hosts cliente

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

Monitore o uso de CPU de todo o sistema do cliente usando métricas disponíveis no portal do Azure ou por meio de contadores de desempenho no computador. Tenha cuidado para não monitorar a CPU do processo, porque um único processo pode representar pouco uso da CPU enquanto o uso de CPU do sistema geral pode ser alto. Fique atento a picos de uso de CPU que correspondem aos tempos limite. O alto uso da CPU também pode causar valores in: XXX altos em mensagens de erro TimeoutException, conforme descrito na seção [Intermitência de tráfego].

Observação

O StackExchange 1.1.603 e versões posteriores incluem a métrica local-cpu em mensagens de erro TimeoutException. Você deve estar usando a versão mais recente do Pacote NuGet do StackExchange.Redis. Os bugs são corrigidos regularmente no código para torná-los mais robustos quanto a tempos limite. Ter a versão mais recente é importante.

Para atenuar o alto uso da CPU de um cliente:

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

Limitação de largura de banda de rede em hosts cliente

Dependendo da arquitetura dos computadores cliente, eles poderão apresentar limitações na largura de banda de rede disponível. Se o cliente exceder a largura de banda disponível, sobrecarregando a capacidade da rede, os dados não serão processados no lado do cliente com a mesma velocidade que o servidor os envia. Essa situação pode resultar em tempos limite excedidos.

Monitore como o uso de Largura de Banda muda ao longo do tempo usando um exemplo BandwidthLogger. Esse código pode não ser executado corretamente 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, confira Tamanho de solicitação ou resposta grande.

Configurações TCP para aplicativos cliente baseados no Linux

Devido a configurações de TCP otimistas no Linux, os aplicativos cliente hospedados no Linux podem apresentar problemas de conectividade. Para obter mais informações, confira Configurações TCP para aplicativos cliente hospedados no Linux

Tempo limite de nova tentativa atingido para RedisSessionStateProvider

Ao usar RedisSessionStateProvider, verifique se você configurou corretamente o tempo limite para novas tentativas. Normalmente, o valor de retryTimeoutInMilliseconds deve ser maior que o de operationTimeoutInMilliseconds. Caso contrário, nenhuma nova tentativa ocorrerá. No exemplo a seguir, retryTimeoutInMilliseconds é definido como 3000. Para obter mais informações, consulte provedor de estado de sessão ASP.NET para Cache do Azure para Redis 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

Veja a seguir a solução de problemas do servidor.

Manutenção do servidor

A manutenção planejada ou não planejada pode causar interrupções nas conexões do cliente. O número e o tipo de exceções dependem da localização da solicitação no caminho do código e de quando o cache fecha as próprias conexõ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 ocorra com êxito.

Para obter mais informações, confira estas outras seções:

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

Para obter mais informações sobre failovers, confira Failover e a patch para Cache do Azure para Redis.

Carga do servidor alta

Alta carga do servidor significa que o servidor Redis não consegue acompanhar as solicitações, fazendo com que tempos limite sejam atingidos. O servidor pode estar lento para responder e impossibilitado de acompanhar as taxas de solicitação.

Monitore métricas como carga do servidor. Fique atento a picos de uso de Server Load que correspondem a tempos limite sendo atingidos. Crie alertas para métricas de carga do servidor a fim de ser notificado com antecedência sobre possíveis impactos.

Há várias alterações que você pode fazer para reduzir a carga alta do servidor:

  • Investigue o que está causando o aumento da carga do servidor, como comandos de execução prolongada indicados neste artigo devido à alta demanda de memória.
  • Escale o ambiente horizontalmente para mais fragmentos a fim de distribuir a carga entre vários processos do Redis ou escale o ambiente verticalmente para um tamanho de cache maior com mais núcleos de CPU. Para obter mais informações, confira Perguntas frequentes de planejamento do Cache do Azure para Redis.
  • Se a carga de trabalho de produção em um cache C1 for afetada negativamente pela latência extra de algumas execuções de verificação interna do Defender, você poderá reduzir o efeito ao escalar para uma oferta de camada de serviço mais alta com vários núcleos de CPU, como C2.

Picos na carga do servidor

Nos caches C0 e C1, você pode ver picos curtos na carga do servidor não causados por um aumento nas solicitações algumas vezes por dia enquanto a verificação interna do Defender está em execução nas VMs. Você perceberá maior latência nas solicitações durante as verificações internas do Defender nesses níveis. Os caches nas camadas C0 e C1 têm apenas um núcleo para multitarefa, dividindo o trabalho de serviço de verificação do Defender e solicitações Redis.

Alto uso da memória

Esta seção foi movida. Para obter mais informações, confira Uso de memória alto.

Comandos de execução prolongada

Alguns comandos Redis são mais caros de serem executados do que outros. A documentação de comandos do Redis mostra a complexidade do tempo de cada comando. O processamento de comandos do Redis é de thread único. Qualquer comando que leva muito tempo para ser executado pode bloquear todos os outros que vêm depois dele.

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

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

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

  • SLOWLOG é usado para ler e redefinir o log de consultas lentas do Redis. Ele pode ser usado para investigar comandos de execução prolongada no lado do cliente. O Log Lento do Redis é 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 conversar 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 e registrar os comandos caros que estão sendo executados no servidor Redis deles usando o comando SLOWLOG.
  • MONITOR é um comando de depuração que transmite de volta todos os comandos processados pelo servidor Redis. Ele pode ajudar a entender o que está acontecendo com o banco de dados. Esse comando é exigente e pode afetar negativamente o desempenho. Ele pode causar degradação do desempenho.
  • INFO – o comando retorna informações e estatísticas sobre o servidor em um formato 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 está ocupado o tempo todo e nunca fica ocioso quando está processando 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 – retorna informações e estatísticas sobre o servidor de conexões de cliente em um formato geralmente legível por humanos.

Limitação de largura de banda de rede

Diferentes tamanhos de cache têm capacidades de largura de banda de rede diferentes. Se o servidor excede a largura de banda disponível, os dados não são enviados ao cliente tão rapidamente. As solicitações de clientes podem atingir o tempo limite porque o servidor não consegue enviar dados por push para o cliente rápido o suficiente.

As métricas de "leitura de cache" e "gravação de cache" podem ser usadas para ver quanto largura de banda do servidor está sendo usada. Você pode exibir essas métricas no Portal. Crie alertas sobre métricas como leitura de cache ou gravação de cache para ser notificado antecipadamente sobre possíveis impactos.

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

Exceções de tempo limite do StackExchange.Redis

Para obter informações mais específicas para resolver problemas de tempo limite atingido ao usar StackExchange.Redis, confira Investigando exceções de tempo limite atingido no StackExchange.Redis.

Conteúdo relacionado