Como soluciono problemas de alta latência no ElastiCache para Valkey ou no ElastiCache para Redis OSS?

Breve descrição

Seguem as causas comuns de problemas de alta latência nos clusters do ElastiCache para Valkey ou ElastiCache para Redis OSS:

• Comandos lentos
• Aumento da atividade de swap devido ao alto uso de memória
• Problemas de rede
• Problemas de latência do lado do cliente
• Sincronização do Redis
• Eventos de cluster do Amazon ElastiCache

Resolução

Comandos lentos

Como os clusters Valkey e Redis OSS são de thread único, o ElastiCache não pode atender aos clientes até que a solicitação atual seja concluída. Essa lentidão resulta em um aumento no tempo total das solicitações e causa alta latência.

Para monitorar a latência média, é possível usar as Amazon CloudWatch Metrics para Valkey e Redis para monitorar comandos específicos. Para mais informações, consulte Métricas para Valkey e Redis OSS.

Para recuperar uma lista de comandos que levam mais de 10 ms para serem processados pelo mecanismo, use o comando SLOWLOG GET. É possível se conectar ao nó afetado para executar o comando slowlog get 128 em valkey-cli.

Além disso, o ElastiCache calcula operações comuns do Redis em latência de microssegundos. O CloudWatch coleta amostras de métricas a cada minuto e mostra métricas de latência como um agregado de vários comandos. Um único comando pode resultar em pequenos problemas, como tempos limite, sem mudanças significativas nos grafos de métrica.

Comandos lentos que demoram muito para serem concluídos podem aumentar o uso da CPU no nó do ElastiCache. Se houver um aumento na métrica EngineCPUUtilization, consulte Como soluciono problemas com o aumento do uso da CPU em meu cluster autoprojetado do ElastiCache for Redis?

Veja a seguir exemplos de comandos complexos que podem tornar os clusters do ElastiCache mais lentos:

• O uso do comando KEYS em ambientes de produção com grandes conjuntos de dados: O comando KEYS varre todo o espaço de chaves e pesquisa padrões específicos. Para mais informações, consulte KEYS no site do Valkey.
• Comando scripts Lua que demora muito para ser executado: Dependendo da complexidade de um script ou do tamanho de um conjunto de dados, o comando scripts Lua pode ser executado por muito tempo e causar problemas de latência.

Aumento da atividade de swap devido ao alto uso de memória

Quando há uma maior pressão de memória no cluster, o Redis troca as páginas de memória. Como as páginas de memória são transferidas de e para a área de swap, a troca pode aumentar a latência e atingir tempos limite. As seguintes mudanças nas CloudWatch Metrics são sinais de que há um aumento na atividade de swap:

• Aumento do SwapUsage
• FreeableMemory baixo
• Métricas de BytesUsedForCache e DatabaseMemoryUsagePercentage altas

Para solucionar o aumento da atividade de swap, leia os seguintes artigos:

• How do I resolve the increase in swap activity in my ElastiCache instances? (Como resolvo o aumento na atividade de swap em minhas instâncias do ElastiCache?)
• Como posso verificar o uso de memória em meu cluster autodesenvolvido do ElastiCache para Redis e implementar práticas recomendadas para controlar o alto uso de memória?

Problemas de rede

Problemas de rede podem causar alta latência em seus clusters. Com base no seu problema de rede, conclua as tarefas a seguir para solucionar problemas de alta latência.

Latência de rede entre o cliente e o cluster do ElastiCache

Para reduzir a latência entre o cliente e seu cluster do ElastiCache, é possível isolar a latência da rede entre os nós do cliente e do cluster. Para mais informações, consulte How do I troubleshoot network performance issues between EC2 Linux or Windows instances in a virtual private cloud (VPC) and an on-premises host over the internet gateway? (Como soluciono problemas de desempenho de rede entre instâncias Linux ou Windows do EC2 em uma nuvem privada virtual (VPC) e um host on-premises pelo gateway da Internet?)

O cluster atinge os limites da rede

Um nó do ElastiCache compartilha os mesmos limites de rede das instâncias relacionadas do Amazon Elastic Compute Cloud (Amazon EC2). Por exemplo, os limites de rede para o tipo de nó cache.m6g.large do ElastiCache e a instância m6g.large do Amazon EC2 são os mesmos. Para mais informações sobre os tipos de nós compatíveis do ElastiCache e os limites de largura de banda da rede, consulte Tipos de nós suportados.

Para solucionar problemas de limites de rede de nós do ElastiCache, consulte Limites relacionados à rede.

Observação: é uma prática recomendada monitorar o desempenho da rede da instância do Amazon EC2, a capacidade de largura de banda, o desempenho do pacote por segundo (PPS) e as conexões rastreadas.

Latência de handshake TCP/SSL

Quando os clientes se conectam aos clusters do Redis, a criação da conexão TCP pode levar alguns milissegundos. Durante esse período, o atraso pode adicionar mais pressão nas operações do Redis e na CPU do nó do ElastiCache. Quando você tem muitas conexões novas, a tensão pode causar alta latência para sua rede.

Para controlar o volume das suas conexões e reduzir a latência, é possível usar um grupo de conexões para armazenar em cache as conexões TCP estabelecidas em um grupo. Para configurar um grupo de conexões, use sua biblioteca cliente do Redis. Ou é possível criar manualmente seu grupo de conexões.

Para otimizar seu grupo de conexões, também é possível usar comandos agregados, como MSET ou MGET, ou pipelines do Redis. Para obter mais informações, consulte Redis pipelining no site do Redis.

Há um grande número de conexões no nó do ElastiCache

Se houver um grande número de conexões TCP em um nó do ElastiCache, você poderá esgotar o limite de maxclients. Quando você atinge esse limite, recebe um erro de "ERR max number of clients reached" e pode enfrentar tempos limite de conexão.

Para diminuir a alta latência, é uma prática recomendada rastrear as métricas CurrConnections e NewConnections do CloudWatch. É possível monitorar essas métricas para ver o número de conexões TCP que seu nó do ElastiCache tem. Para resolver problemas ao esgotar seu limite de maxclients, consulte a seção Grande número de conexões das Práticas recomendadas: Clientes Redis e Amazon ElastiCache para Redis.

Problemas de latência do lado do cliente

Se você configurar os recursos do cliente com valores de tempo limite muito baixos, poderá receber erros de tempo limite. Para determinar se os recursos do cliente causam problemas de latência, verifique a utilização da memória, da CPU e da rede no lado do cliente. Se esses recursos estiverem próximos dos limites, configure os valores de tempo limite do lado do cliente para um valor maior para que o recurso possa responder.

Se a aplicação for executada em uma instância do Amazon EC2, é possível usar as CloudWatch Metrics para identificar os problemas. Ou use uma ferramenta de monitoramento dentro da instância do Amazon EC2, como um atop ou agente do CloudWatch.

Para determinar se o cliente é a causa da alta latência, procure os seguintes problemas:

• Verifique se os tempos limite ocorrem com frequência ou em um horário específico do dia.
• Verifique se os tempos limite ocorrem em um cliente específico ou em vários clientes.
• Verifique se os tempos limite ocorrem em um nó Valkey ou Redis específico ou em vários nós.
• Verifique se os tempos limite ocorrem em um cluster específico ou em vários clusters.

Sincronização do Redis

A sincronização do Redis é iniciada nos eventos de backup, substituição de nós e escalabilidade. Esse processo é um workload que exige muita computação e pode causar latências.

Para verificar se uma sincronização afetou o desempenho do seu nó, é possível verificar a métrica SaveInProgress no CloudWatch.

Observação: para minimizar os efeitos no tráfego de usuários, é uma prática recomendada programar eventos de sincronização fora do horário de pico.

Eventos de cluster do ElastiCache

Se seu cluster do ElastiCache tiver um evento de cluster, você poderá experimentar uma alta latência durante o evento. É possível usar o console do ElastiCache para analisar eventos durante o período de latência. Verifique as atividades em segundo plano, como substituição de nós ou eventos de failover de manutenção gerenciada e atualizações de serviços do ElastiCache.

Se você acha que falhas inesperadas de hardware causaram alta latência, entre em contato com o AWS Support.

Observação: é possível consultar as notificações de eventos programados no AWS Health Dashboard.

Exemplo de log de eventos:

Finished recovery for cache nodes 0001
Recovering cache nodes 0001
Failover from master node cluster_node to replica node cluster_node completed

Informações relacionadas

Práticas recomendadas de monitoramento com o Amazon ElastiCache para Redis usando o Amazon CloudWatch

Problemas persistentes de conexão

Como faço para ativar a entrega de logs em um cluster do ElastiCache para Redis OSS ou ElastiCache para Valkey?