Partilhar via

Resolver problemas de latência e timeouts do Azure Cache para Redis

  • Aplica-se a: ✅ Azure Cache for Redis

Uma operação do cliente do Azure Cache para Redis que não recebe uma resposta em tempo hábil pode causar alta latência ou uma exceção de tempo limite. Este artigo explica como solucionar problemas comuns que podem levar a alta latência e tempos limites.

Uma operação pode enfrentar problemas ou atingir o tempo limite em vários estágios. A origem do problema ajuda a determinar a causa e a atenuação. Este artigo é dividido em problemas do lado do cliente e do lado do servidor.

Problemas do lado do cliente

Problemas do lado do servidor

Resolução de problemas no lado do cliente

Os seguintes problemas do lado do cliente podem afetar a latência e o desempenho e levar a timeouts.

Conexões de cliente altas

Os pedidos de conexão de cliente que excedem o limite máximo para o cache podem falhar. Conexões de cliente altas também podem causar alta carga no servidor ao processar repetidas tentativas de reconexão.

Conexões de cliente altas podem indicar um vazamento de conexão no código do cliente. As conexões podem não estar sendo reutilizadas ou fechadas corretamente. Revise o código do cliente para uso da conexão.

Se as conexões altas forem todas legítimas e necessárias, talvez seja necessário atualizar o cache para um tamanho com um limite de conexão mais alto. Verifique se a agregação máxima para a métrica Clientes conectados está próxima ou acima do número máximo de conexões permitidas para o tamanho do cache. Para obter mais informações sobre o dimensionamento por conexões de cliente, consulte Azure Cache for Redis desempenho.

CPU elevada nos hosts 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 envie a resposta rapidamente, o cliente pode não conseguir processar a resposta com rapidez suficiente. É melhor manter a CPU do cliente a menos de 80%.

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

  • Investigue a causa dos picos de CPU.
  • Atualize seu cliente para um tamanho maior de máquina virtual (VM) com mais capacidade de CPU.

Monitore o uso da CPU em todo o sistema do cliente usando métricas disponíveis no portal do Azure ou por meio de contadores de desempenho na VM. Verifique a métrica Errors (Type: UnresponsiveClients) para determinar se os hosts do cliente podem processar respostas do servidor Redis a tempo.

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. Esteja atento aos picos de utilização da CPU que correspondem aos timeouts. CPU alta também pode causar valores altos in: XXX em timeoutException mensagens de erro. Consulte a seção Configuração do pool de threads e intermitência de tráfego para obter um exemplo.

O StackExchange.Redis 1.1.603 e posterior inclui a local-cpu métrica nas timeoutException mensagens de erro. Certifique-se de usar a versão mais recente do pacote NuGet StackExchange.Redis, porque os bugs são corrigidos regularmente para tornar o código mais resistente a tempos limites. Para obter mais informações, consulte Investigando timeout exceções no StackExchange.Redis.

Grandes valores-chave

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

Para mitigar o problema:

  • 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 o uso atual da rede em ambas as VMs com os limites dos tamanhos atuais das VMs. Mais largura de banda apenas no servidor ou cliente pode não ser suficiente.

  • Aumente o número de objetos de ligação que a sua aplicação utiliza. Use uma abordagem round-robin para fazer solicitações em diferentes objetos de conexão. Para obter informações sobre como utilizar várias chaves e valores mais pequenos, consulte Considerar mais chaves e valores mais pequenos.

Pressão de memória no cliente Redis

A pressão de memória sobre o cliente pode levar a problemas de desempenho que atrasam o processamento de respostas de cache. Quando ocorre pressão de memória, o sistema poderá paginar dados para o disco. Esta falha de página faz com que o sistema fique significativamente lento.

Para detetar a pressão da memória no cliente:

  • Monitore o uso de memória na VM para garantir que ela não exceda a memória disponível.
  • Monitore o contador de desempenho do Page Faults/Sec cliente. Durante a operação normal, a maioria dos sistemas tem algumas falhas de página. Picos de falhas de página correspondentes a tempos limite de solicitação podem indicar pressão de memória.

Para atenuar a alta pressão de memória no cliente:

  • Investigue seus padrões de uso de memória para reduzir o consumo de memória no cliente.
  • Atualize sua VM cliente para um tamanho maior com mais memória.

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

Dependendo de sua arquitetura, as máquinas cliente podem ter limitações na disponibilidade de largura de banda da rede. 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 tão rapidamente quanto o servidor os está enviando. 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.

RedisSessionStateProvider retryTimeout

Se utilizar RedisSessionStateProvider, certifique-se de configurar retryTimeout corretamente. O valor de retryTimeoutInMilliseconds deve ser superior ao valor de operationTimeoutInMilliseconds. Caso contrário, não ocorrerão repetições.

No exemplo a seguir, retryTimeoutInMilliseconds é definido como 3000.

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

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

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

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 verificar se os hosts do cliente conseguem lidar com picos repentinos de tráfego. Você pode definir as configurações do ThreadPool para garantir que o pool de threads seja dimensionado rapidamente em cenários de intermitência.

Você pode usar timeoutException mensagens de StackExchange.Redis para investigar 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)

A exceção anterior demonstra vários problemas.

  • nas secções IOCP e WORKER, o valor Busy é maior do que o valor Min, o que significa que as configurações ThreadPool precisam ser ajustadas.
  • O valor in: 64221 indica que 64.221 bytes foram recebidos na camada de soquete do kernel do cliente, mas não 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.

O StackExchange.Redis 1.1.603 e posterior inclui a local-cpu métrica nas timeoutException mensagens de erro. Certifique-se de usar a versão mais recente do pacote NuGet StackExchange.Redis, porque os bugs são corrigidos regularmente para tornar o código mais resistente a tempos limites. Para obter mais informações, consulte Investigando exceções de tempo limite em StackExchange.Redis.

Resolução de problemas do lado do servidor

Os seguintes problemas do lado do servidor podem afetar o desempenho e levar a timeouts.

Elevada utilização da memória

A pressão de memória no servidor pode levar a vários problemas de desempenho que atrasam o processamento da solicitação. Quando ocorre pressão de memória, o sistema armazena dados no disco, o que faz com que o sistema fique significativamente lento.

Algumas causas possíveis de pressão de memória são que o cache é preenchido com dados para perto de sua capacidade máxima, ou que o servidor Redis tem alta fragmentação de memória.

A fragmentação é provável quando um padrão de carga está armazenando dados com alta variação de tamanho, por exemplo, quando os dados são distribuídos em tamanhos de 1 KB e 1 MB. Quando uma chave de 1 KB é excluída da memória existente, uma chave de 1 MB não cabe no espaço, causando fragmentação. Da mesma forma, se a chave de 1 MB for excluída, uma chave de 1,5 MB adicionada não poderá caber na memória recuperada existente. Esta memória livre não utilizada resulta em fragmentação.

Se um cache estiver fragmentado e estiver sendo executado sob alta pressão de memória, o sistema fará um failover para tentar recuperar a memória RSS (Resident set Size). O Redis expõe duas estatísticas, used_memory e used_memory_rss, através do comando INFO , que pode ajudá-lo a identificar esse problema. Você também pode exibir essas métricas no portal do Azure.

Se o valor used_memory_rss for superior a 1,5 vezes a métrica used_memory, há fragmentação na memória. A fragmentação pode causar problemas quando:

  • O uso de memória está próximo do limite máximo de memória para o cache.
  • A used_memory_rss métrica é maior do que o limite máximo de memória, potencialmente resultando em falha de página na memória.

Você pode tomar várias ações para ajudar a manter o uso da memória saudável.

Para obter mais recomendações sobre gerenciamento de memória, consulte Práticas recomendadas para gerenciamento de memória.

Carga do servidor elevada

Alta carga do servidor significa que o servidor Redis está ocupado e incapaz de acompanhar as solicitações, levando a tempos limite ou respostas lentas. Para reduzir a alta carga do servidor, primeiro investigue a causa, como comandos de longa execução devido à alta pressão de memória.

Você pode monitorar métricas como a carga do servidor no portal do Azure. Para verificar a métrica Carga do servidor , selecione Insights em Monitoramento no menu de navegação esquerdo na página de cache e visualize o gráfico Carga do servidor . Ou selecione Métricas em Monitoramento no menu de navegação esquerdo e, em seguida, selecione Carga do servidor em Métricas.

Observe os picos de utilização de Carga do Servidor que correspondem com timeouts. Crie alertas sobre métricas de carga do servidor para ser notificado antecipadamente sobre possíveis impactos.

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, enquanto a verificação interna do Defender está sendo executada nas VMs. Nessas camadas, você vê latência mais alta para solicitações enquanto ocorrem verificações internas do Defender.

O cache nas camadas C0 e C1 tem apenas um único núcleo para a execução de múltiplas tarefas em simultâneo, dividindo o trabalho de atender às verificações internas do Defender e às solicitações do Redis. Se a latência extra das verificações internas do Defender afetar negativamente a sua carga de trabalho de produção num cache C1, pode escalar para uma oferta de nível superior com vários núcleos de CPU, como o C2. Para obter mais informações, consulte Escolher o nível adequado.

Para obter mais informações sobre alterações rápidas no número de conexões de cliente, consulte Evitar picos de conexão de cliente.

Escalonamento

Você pode expandir para mais fragmentos para distribuir a carga em vários processos Redis ou escalar para um tamanho de cache maior com mais núcleos de CPU. As operações de dimensionamento consomem muita CPU e memória, pois podem envolver a movimentação de dados entre nós e a alteração da topologia do cluster. Para obter mais informações, consulte Perguntas frequentes sobre planejamento e dimensionamento do Cache do Azure para Redis.

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 temporal de cada comando. O processamento de comandos do Redis é de thread único. Qualquer comando que demore muito tempo a ser executado pode bloquear outros que o seguem.

Analise os comandos que você emite para seu servidor Redis para entender seus impactos no desempenho. Por exemplo, o comando KEYS é frequentemente usado sem o conhecimento de que é uma operação Big O Notation (O(N)). Para reduzir os picos de CPU, você pode evitar KEYS usando SCAN.

Você pode executar os seguintes comandos Redis em um console para investigar comandos caros e de longa execução.

  • LISTA DE CLIENTES

    O CLIENT LIST comando retorna informações e estatísticas sobre o servidor de conexões de cliente em um formato legível principalmente por humanos.

  • INFORMAÇÃO

    O INFO comando retorna informações e estatísticas sobre o servidor em um formato que é simples para os computadores analisarem e fácil para os seres humanos lerem. A CPU seção pode ser útil para investigar o uso da CPU. A server_load de 100 (valor máximo) significa que o servidor Redis estava ocupado o tempo todo e nunca estava ocioso ao processar as solicitações.

    O exemplo a seguir mostra uma saída do INFO comando:

    # 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

  • MONITOR

    MONITOR é um comando de depuração que transmite de volta todos os comandos processados pelo servidor Redis. MONITOR pode ajudá-lo a entender o que está acontecendo com o banco de dados. Este comando é exigente e pode afetar negativamente e degradar o desempenho.

  • SLOWLOG

    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, como falar com o cliente ou enviar a resposta, mas apenas o tempo necessário para realmente executar o comando.

    O SLOWLOG comando lê e redefine o log de consultas lentas do Redis e também pode ser usado para investigar comandos de longa execução no lado do cliente. Você pode monitorar e registrar comandos caros sendo executados no servidor Redis usando SLOWLOG GET.

Limitações 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. Os pedidos dos clientes podem expirar porque o servidor não consegue enviar os dados para o cliente com rapidez suficiente.

Você pode monitorar métricas como Leitura de Cache e Gravação de Cache no portal do Azure para ver quanta largura de banda do lado do servidor está sendo usada. Crie alertas sobre essas métricas para ser notificado antecipadamente sobre possíveis 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 Perguntas frequentes sobre planejamento do Cache do Azure para Redis.

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 dependem do local da solicitação no caminho do código e quando o cache fecha suas conexões.

Se o cache Redis do Azure passar por um failover, todas as conexões de cliente do nó que ficou inativo serão transferidas para o nó que ainda está em execução. A carga do servidor pode aumentar devido ao aumento das conexões. Você pode tentar reinicializar seus aplicativos cliente para que todas as conexões de cliente sejam recriadas e redistribuídas entre os dois nós.

Uma operação que envia uma solicitação, mas não recebe uma resposta quando o failover ocorre, pode obter uma timeout exceção. 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 verificar se o cache do Azure Redis sofreu um failover durante o tempo em que ocorreram as tuas exceções timeout, consulta a métrica Erros. Na página do portal do Azure para seu cache, selecione Métricas em Monitoramento no menu de navegação esquerdo. Em seguida, crie um novo gráfico medindo a métrica Erros , 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.

Para obter mais informações sobre como atenuar problemas devido à manutenção do servidor, consulte os seguintes artigos:

Conteúdos relacionados