Como soluciono problemas de alta latência ao usar o ElastiCache para Redis?
Como soluciono problemas de alta latência ao usar o Amazon ElastiCache para Redis?
Breve descrição
Veja a seguir motivos comuns para latências elevadas ou problemas de tempo limite no ElastiCache para Redis:
- Latência causada por comandos lentos.
- Alto uso de memória levando ao aumento de trocas.
- Latência causada por problemas de rede.
- Problemas de latência do lado do cliente.
- Eventos de cluster do ElastiCache.
Resolução
Latência causada por comandos lentos
O Redis usa majoritariamente um único thread. Portanto, quando uma solicitação demora para ser atendida, todos os outros clientes devem esperar para serem atendidos. Essa espera aumenta as latências dos comandos. Os comandos do Redis também têm uma complexidade de tempo definida usando a notação Big O.
Use as métricas do Amazon CloudWatch fornecidas pelo ElastiCache para monitorar a latência média para diferentes classes de comandos. É importante observar que as operações comuns do Redis são calculadas em latência de microssegundos. As métricas do CloudWatch são amostradas a cada 1 minuto, com as métricas de latência mostrando um agregado de vários comandos. Portanto, um único comando pode causar resultados inesperados, como tempos limites esgotados, sem apresentar mudanças significativas nos gráficos de métricas. Nessas situações, use o comando SLOWLOG para ajudar a determinar que comandos estão demorando mais para serem concluídos. Conecte-se ao cluster e execute o comando slowlog get 128 na redis-cli para recuperar a lista. Para obter mais informações, consulte Como ativar o log Slow do Redis em um cluster de cache do ElastiCache for Redis?
Você também pode ver um aumento na métrica EngineCPUUtilization no CloudWatch devido a comandos lentos que bloqueiam o mecanismo Redis. Para obter mais informações, consulte Por que estou vendo um uso alto ou crescente da CPU no cluster do ElastiCache para Redis?
Exemplos de comandos complexos incluem:
- KEYS em ambientes de produção em grandes conjuntos de dados pois ele que varre todo o keyspace procurando um padrão especificado.
- Scripts LUA de longa execução.
Alto uso de memória, levando ao aumento de trocas
O Redis começa a trocar páginas quando a pressão por memória no cluster aumenta usando mais memória do que a disponível. Os problemas de latência e tempo limite aumentam quando as páginas de memória são transferidas de e para a área de troca. Estas são indicações nas métricas do CloudWatch de aumento nas trocas:
- Aumento de SwapUsage.
- FreeableMemory muito baixa.
- Métricas BytesUsedForCache e DatabaseMemoryUsagePercentage altas.
SwapUsage é uma métrica no nível do host que indica a quantidade de memória que está sendo trocada. É normal que essa métrica mostre valores diferentes de zero porque ela é controlada pelo sistema operacional subjacente e pode ser influenciada por muitos fatores dinâmicos. Esses fatores incluem a versão do sistema operacional, padrões de atividade e assim por diante. O Linux troca proativamente chaves ociosas (raramente acessadas por clientes) para o disco como técnica de otimização para liberar espaço de memória para as chaves usadas com mais frequência.
A troca se torna um problema quando não há memória disponível suficiente. Quando isso acontece, o sistema começa a mover páginas para frente e para trás entre o disco e a memória. Especificamente, SwapUsage menor que algumas centenas de megabytes não afeta negativamente o desempenho do Redis. Haverá impactos no desempenho se SwapUsage for alto e estiver sendo alterado ativamente, e não houver memória suficiente disponível no cluster. Para obter mais informações, consulte:
- Por que estou vendo um consumo de memória alto ou crescente no cluster do ElastiCache?
- Por que a ocorrem trocas no ElastiCache?
Latência causada pela rede
Latência de rede entre o cliente e o cluster do ElastiCache
Para isolar a latência da rede entre os nós do cliente e do cluster, use os testes TCP traceroute ou mtr do ambiente de aplicação. Ou use uma ferramenta de depuração, como o documento AWSSupport-SetupIPMonitoringFromVPC do AWS Systems Manager (documento SSM) para testar conexões da sub-rede do cliente.
O cluster está atingindo os limites da rede
Um nó do ElastiCache compartilha os mesmos limites de rede que o tipo correspondente de instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Por exemplo, o tipo de nó cache.m6g.large tem os mesmos limites de rede que a instância m6g.large do EC2. Para obter informações sobre como verificar os três principais componentes de performance de rede: capacidade de largura de banda, performance em pacotes por segundo (PPS) e conexões rastreadas, consulte Monitorar a performance da rede para a instância do EC2.
Para solucionar problemas de limites de rede no nó do ElastiCache, consulte Solucionar problemas - limites relacionados à rede.
Latência de handshake TCP/SSL
Os clientes se conectam aos clusters do Redis usando uma conexão TCP. Criar uma conexão TCP leva alguns milissegundos. Os milissegundos extras criam uma sobrecarga adicional nas operações do Redis executadas pela aplicação e pressão extra na CPU do Redis. É importante controlar o volume de novas conexões quando o cluster está usando o recurso de criptografia em trânsito do ElastiCache devido ao tempo extra e à utilização da CPU necessários para um handshake TLS. Um alto volume de conexões abertas rapidamente (NewConnections) e fechadas pode afetar a performance do nó. Você pode usar o grupo de conexões para armazenar em cache as conexões TCP estabelecidas com um grupo. As conexões são então reutilizadas sempre que um novo cliente tenta se conectar ao cluster. Você pode implementar o grupo de conexões usando a biblioteca de clientes do Redis (se compatível), com uma estrutura disponível para o ambiente de aplicação ou construí-lo a partir do zero. Você também pode usar comandos agregados, como MSET/MGET, como uma técnica de otimização.
Há um grande número de conexões no nó do ElastiCache.
É uma prática recomendada acompanhar as métricas CurrConnections e NewConnections do CloudWatch. Essas métricas monitoram o número de conexões TCP aceitas pelo Redis. Um grande número de conexões TCP pode levar ao esgotamento do limite de maxclients, que é de 65.000. Esse limite é o máximo de conexões simultâneas que você pode ter por nó. Se você atingir o limite de 65.000, receberá o erro ERR max number of clients reached (ERRO número máximo de clientes atingido). Se mais conexões forem adicionadas além do limite do servidor Linux ou do número máximo de conexões rastreadas, as conexões de cliente adicionais resultarão em erros de tempo limite de conexão. Para obter recomendações sobre como lidar com um grande número de conexões, consulte Práticas recomendadas: clientes do Redis e do Amazon ElastiCache para Redis.
Problemas de latência do lado do cliente
Latência e tempos limite podem ser originados no próprio cliente. Verifique a utilização de memória, CPU e rede no lado do cliente para determinar se algum desses recursos está atingindo seus limites. Se a aplicação estiver sendo executada em uma instância do EC2, aproveite as mesmas métricas do CloudWatch discutidas anteriormente para verificar se há gargalos. A latência pode acontecer em um sistema operacional que não pode ser monitorado completamente pelas métricas padrão do CloudWatch. Considere a instalação de uma ferramenta de monitoramento dentro da instância do EC2, como atop ou agente do CloudWatch.
Se os valores de configuração de tempo limite definidos no lado da aplicação forem muito pequenos, você poderá receber erros de tempo limite desnecessários. Configure o tempo limite do cliente adequadamente para permitir que o servidor tenha tempo suficiente para processar a solicitação e gerar a resposta. Para obter mais informações, consulte Práticas recomendadas: clientes do Redis e do Amazon ElastiCache para Redis para obter mais detalhes.
O erro de tempo limite recebido da aplicação mostra detalhes adicionais. Esses detalhes incluem se um nó específico está envolvido, o nome do tipo de dados do Redis que está causando tempos limites esgotados, o carimbo de data/hora exato quando o tempo limite foi atingido e assim por diante. Essas informações ajudam você a encontrar o padrão do problema. Use essas informações para responder a perguntas como as seguintes:
- Tempos limites esgotados acontecem com frequência durante um horário específico do dia?
- O tempos limite esgotado ocorreu em um cliente ou em vários clientes?
- O tempo limite ocorreu em um nó do Redis ou em vários nós?
- O tempo limite ocorreu em um cluster ou em vários clusters?
Use esses padrões para investigar qual é o cliente ou o nó do ElastiCache mais provável. Você também pode usar o log da aplicação e os logs de fluxo da VPC para determinar se a latência ocorreu no lado do cliente, no nó do ElastiCache ou na rede.
Sincronização do Redis
A sincronização do Redis é iniciada durante eventos de backup, substituição e escalação. Essa é uma workload de computação intensiva que pode causar latências. Use a métrica SaveInProgress do CloudWatch para determinar se a sincronização está em andamento. Para obter mais informações, consulte Como a sincronização e o backup são implementados.
Eventos de cluster do ElastiCache
Verifique a seção Events (Eventos) no console do ElastiCache para saber o período em que a latência foi observada. Verifique se há atividades em segundo plano, como substituição de nó ou eventos de failover que possam ser causados pela Manutenção gerenciada e atualizações de serviço do ElastiCache, ou falhas inesperadas de hardware. Você recebe uma notificação de eventos agendados por meio do painel e e-mail do PHD.
Veja a seguir um 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
Conteúdo relevante
- AWS OFICIALAtualizada há 10 meses
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 anos