Compartilhar via

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

  • Aplica-se a: ✅ Azure Cache for Redis

Importante

O Cache do Azure para Redis anunciou a linha do tempo de desativação para todos os SKUs. Recomendamos migrar suas instâncias do Cache do Azure para Redis para o Redis Gerenciado pelo Azure assim que possível.

Para obter mais detalhes sobre a aposentadoria:

Uma operação de cliente do Azure Cache for Redis que não recebe uma resposta oportuna pode causar alta latência ou uma exceção de timeout. Este artigo explica como solucionar problemas comuns que podem levar a alta latência e tempos limite.

Uma operação pode enfrentar problemas ou expiração de tempo em vários estágios. A origem do problema ajuda a determinar a causa e a mitigaçã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

Solução de problemas do lado do cliente

Os problemas do lado do cliente a seguir podem afetar a latência e o desempenho e resultar em tempos limite.

Altas conexões de cliente

Solicitações de clientes para conexões além do limite máximo do cache podem falhar. Conexões de cliente altas também podem causar alta carga do servidor ao processar tentativas de reconexão repetidas.

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. Examine o código do cliente para uso de conexão.

Se as conexões altas forem todas legítimas e necessárias para conexões de cliente, talvez seja necessário atualizar o cache para um tamanho com um limite de conexão mais alto. Verifique se a métrica de total máximo para Clientes Conectados está próxima ou superior ao 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 o desempenho do Cache do Azure para Redis.

Uso elevado de CPU em hosts cliente

O alto uso da CPU do cliente indica que o sistema não pode acompanhar o trabalho atribuído a ele. Mesmo que o cache envie a resposta rapidamente, o cliente poderá não processar a resposta com rapidez suficiente. É melhor manter a CPU do cliente em menos de 80%.

Para atenuar o alto uso da CPU de um cliente:

  • Investigue a causa dos picos de CPU.
  • Atualize seu cliente para um tamanho maior de VM (máquina virtual) 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 os erros de métrica (Tipo: UnresponsiveClients) para determinar se os hosts cliente podem processar respostas do servidor Redis a tempo.

Tenha cuidado para não monitorar a CPU do processo, pois um único processo pode ter baixo uso de CPU, mas a CPU em todo o sistema pode ser alta. Fique atento a picos de uso de CPU que correspondem aos tempos limite. O alto uso de CPU também pode causar valores altos em mensagens de erro in: XXXtimeoutException. Confira a seção Configuração do pool de threads e intermitência de tráfego para obter um exemplo.

O StackExchange 1.1.603 e versões posteriores incluem a métrica local-cpu em mensagens de erro timeoutException. Use a versão mais recente do pacote NuGet StackExchange.Redis, pois os bugs são corrigidos regularmente para tornar o código mais resistente aos tempos limite. Para obter mais informações, consulte Como investigar timeout exceções no StackExchange.Redis.

Valores chave grandes

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

Para atenuar o problema:

  • Aumente o tamanho da VM para obter recursos de largura de banda mais altos. 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 ambas as VMs com os limites dos tamanhos atuais da VM. Mais largura de banda apenas no servidor ou no cliente pode não ser suficiente.

  • Aumentar o número de objetos de conexão que o aplicativo usa. Use uma abordagem Round Robin para fazer solicitações em diferentes objetos de conexão. Para obter informações sobre como usar várias chaves e valores menores, confira Considerar mais chaves e valores menores.

Pressão de memória no cliente Redis

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

Para detectar a pressão de 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 em falhas de página correspondentes com 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 a VM do cliente para um tamanho maior com mais memória.

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

Dependendo de sua arquitetura, os computadores cliente podem ter limitações na disponibilidade de largura de banda de 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 o está enviando. Essa situação pode resultar em tempos limite excedidos.

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.

RedisSessionStateProvider retryTimeout

Se você usar RedisSessionStateProvider, certifique-se de definir corretamente retryTimeout . 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.

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

Configurações TCP para aplicativos cliente baseados no Linux

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

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 acompanhar picos repentinos no tráfego. Você pode definir as configurações do ThreadPool para garantir que o pool de threads seja escalado rapidamente em cenários de intermitência.

Você pode usar timeoutException mensagens do StackExchange.Redis para investigar mais a fundo.

    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.

  • Na seção IOCP e na seção WORKER, o valor Busy é maior 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.

O StackExchange 1.1.603 e versões posteriores incluem a métrica local-cpu em mensagens de erro timeoutException. Use a versão mais recente do pacote NuGet StackExchange.Redis, pois os bugs são corrigidos regularmente para tornar o código mais resistente aos tempos limite. Para obter mais informações, consulte Investigando exceções de tempo limite no StackExchange.Redis.

Solução de problemas do lado do servidor

Os problemas do lado do servidor a seguir podem afetar o desempenho e levar a tempos limite.

Alto uso 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 pagina dados em disco, o que faz com que o desempenho do sistema diminua significativamente.

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

A fragmentação é provável quando um padrão de carga está armazenando dados com variação de alto tamanho, por exemplo, quando os dados são distribuídos entre 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 pode caber 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. Essa memória livre não utilizada resulta em fragmentação.

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

Se o used_memory_rss valor for maior que 1,5 vezes a used_memory métrica, haverá 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 métrica used_memory_rss é maior que o limite máximo de memória, potencialmente resultando em falha de página na memória.

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

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

Carga do servidor alta

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

Você pode monitorar métricas como o carregamento do servidor no portal do Azure. Para verificar a métrica de Carga do Servidor , selecione Insights em Monitoramento no menu de navegação à esquerda na página de cache e exiba o grafo de Carga do Servidor . Ou selecione Métricas em Monitoramento no menu de navegação à esquerda e selecione Carga do Servidor em Métricas.

Observe os picos no uso da Carga do Servidor que correspondem aos tempos limite. Crie alertas nas métricas de carga do servidor para serem notificados 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á em execução nas VMs. Nessas camadas, você verá uma latência maior para solicitações enquanto ocorrem verificações internas do Defender.

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. Se a latência extra das verificações internas do Defender afetar negativamente sua carga de trabalho de produção em um cache C1, você poderá escalar para uma oferta de camada superior com vários núcleos de CPU, como C2. Para obter mais informações, consulte Escolhendo a camada certa.

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

Scaling

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

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 leve muito tempo para ser executado pode bloquear outras pessoas que o seguem.

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

Você pode executar os seguintes comandos Redis em um console para investigar comandos que demoram para executar e são caros.

  • LISTA DE CLIENTES

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

  • INFORMAÇÃO

    O INFO comando retorna informações e estatísticas sobre o servidor em um formato simples para computadores analisarem e facilitarem a leitura de humanos. A CPU seção pode ser útil para investigar o uso da CPU. Um server_load de 100 (valor máximo) indica que o servidor Redis estava ocupado o tempo todo e nunca esteve ocioso ao processar as requisiçõ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 todos os comandos processados pelo servidor Redis. MONITOR pode ajudá-lo a entender o que está acontecendo com o banco de dados. Esse comando é exigente e pode afetar e degradar negativamente o desempenho.

  • SLOWLOG

    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 ou enviar a resposta, mas apenas o tempo necessário para 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 execução prolongada no lado do cliente. Você pode monitorar e registrar comandos caros sendo executados no servidor Redis usando SLOWLOG GET.

Limitações de largura de banda de rede

Diferentes tamanhos de cache têm capacidades de largura de banda de rede diferentes. Se o servidor exceder a largura de banda disponível, os dados não serã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.

Você pode monitorar métricas como Leitura de Cache e Gravação em Cache no portal do Azure para ver a quantidade de largura de banda do lado do servidor que está sendo usada. Crie alertas sobre essas métricas para serem notificados 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:

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 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 foi desativado 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 ocorre o failover, pode obter uma timeout exceção. Novas solicitações no objeto de conexão fechado recebem exceções de conexão até que a reconexão ocorra com êxito.

Para verificar se o cache Redis do Azure sofreu um failover durante o período em que suas exceções timeout ocorreram, verifique a métrica Erros. Na página do portal do Azure para o cache, selecione Métricas em Monitoramento no menu de navegação à esquerda. Em seguida, crie um novo gráfico medindo a métrica Erros , dividido 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.

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

Conteúdo relacionado

  • Last updated on