Por que estou vendo um consumo de memória alto ou crescente no meu cluster do ElastiCache?

Data da última atualização: 15/09/2022

Estou vendo um consumo de memória alto ou crescente no meu cluster do Amazon ElastiCache. Como o uso de memória é determinado nos nós de cluster do ElastiCache?

Resolução

Para determinar o uso geral de memória em seu cluster e seus nós, revise estas métricas do Redis. Essas métricas são publicadas no Amazon CloudWatch para cada nó em um cluster:

  • BytesUsedForCache: o número total de bytes alocados pelo Redis para conjuntos de dados, buffers e assim por diante. Essa métrica é derivada da saída do comando INFO de um nó do Redis. Use essa métrica para determinar a utilização da memória do cluster.
  • FreeableMemory: essa métrica no nível do host mostra a quantidade de memória livre disponível no host. Quando o uso da memória aumenta devido a dados de cache ou por sobrecarga, você pode ver a diminuição em FreeableMemory. Uma diminuição em FreeableMemory sugere pouca memória livre no host. A troca pode ocorrer se FreeableMemory estiver muito baixo.
  • DataBaseMemoryUsagePercentage: essa métrica é derivada da saída do comando Redis INFO. Essa é a porcentagem de memória usada pelo nó do cluster. O Redis inicia a política de remoção de maxmemory do Redis depois que essa métrica atinge 100% do limite.

Lembre-se de que, por padrão, o ElastiCache para Redis reserva 25% da memória máxima para uso não relacionado a dados, como failover e backup. Se você não especificar memória reservada suficiente para uso não relacionado a dados, a chance de swap aumenta. Para obter mais informações, consulte Gerenciar memória reservada.

Causas do uso repentino de memória

  • Chaves adicionadas recentemente: a adição de novos pares de chave-valor causa um aumento no uso da memória. Adicionar elementos em chaves existentes também aumenta o uso da memória. Verifique a métrica SetTypeCmds para determinar se há alterações de dados recentes no nó. Essa métrica registra o número total de comandos do tipo gravação e é derivada da estatística Commandstats do Redis.
  • Aumento no uso do buffer: os clientes estão conectados ao Redis pela rede. Se o cliente não estiver lendo do cache com rapidez suficiente, o Redis manterá os dados de resposta em um espaço de memória chamado buffer de saída do cliente. O cliente pode continuar lendo a partir do espaço do buffer. Isso também vale para clientes Pub e Sub se os clientes inscritos não estiverem lendo rápido o suficiente.
    Se houver um gargalo na largura de banda da rede ou se o cluster estiver continuamente sob carga pesada, o uso do buffer poderá continuar a se acumular. Esse acúmulo causa esgotamento da memória e degradação da performance. Por padrão, o ElastiCache para Redis não restringe o crescimento no buffer de saída e cada um dos clientes tem seu próprio buffer. Use o comando client-list para verificar o uso do buffer.
  • Grande número de novas conexões: um grande número de novas conexões pode elevar o uso da memória. Todas as novas conexões criam um descritor de arquivo que consome memória. O consumo agregado de memória com um grande número de novas conexões pode ser alto, levando a remoção de dados ou erros de OOM. Verifique a métrica NewConnections para ver o número total de novas conexões aceitas.
  • Alto uso de swap: é normal ver algum uso de swap em um nó de cache quando há memória livre. No entanto, o uso excessivo de swap pode levar a problemas de performance. O alto swap geralmente começa a acontecer em um nó que está sendo executado sob pressão de memória, resultando em pouca memória liberável. Use a métrica SwapUsage para monitorar o swap no host.
  • Alta fragmentação de memória: uma alta fragmentação de memória indica ineficiências no gerenciamento de memória no sistema operacional. O Redis pode não liberar memória quando as chaves são removidas. Use a métrica MemoryFragmentationRatio para monitorar a taxa de fragmentação. Se você estiver enfrentando problemas de fragmentação, ative o parâmetro activedefrag para ativar a desfragmentação ativa da memória.
  • Chaves grandes: uma chave com um grande tamanho de dados ou um grande número de elementos é chamada de chave grande. Você pode perceber um alto consumo de memória como resultado de chaves grandes, mesmo que a métrica CurrItems permaneça baixa. Para detectar chaves grandes em seu conjunto de dados, use o comando redis-cli --bigkeys.

Práticas recomendadas para controlar o alto consumo de memória

  • Usar TTL nas chaves: você pode especificar TTL nas chaves para determinar a expiração. Isso remove as chaves após a expiração sem esperar pela pressão da memória. Isso evita sobrecarregar o Redis com chaves desnecessárias. Um pequeno número de remoções não é uma preocupação, mas um alto número de remoções significa que seu nó está sendo executado sob pressão de memória.
  • Usar política de remoção: quando a memória cache começa a encher, o Redis remove as chaves para liberar espaço com base na política maxmemory-policy. A política padrão maxmemory-policy é definida como volatile_lru. É uma prática recomendada escolher uma política de remoção específica para as necessidades de sua workload.
  • Alocar memória reservada: para evitar problemas durante o failover ou backup, é uma prática recomendada definir reserved_memory_percentage como pelo menos 25% para uso não relacionado a dados. Se não houver memória reservada suficiente para realizar failover ou backup, ocorrerão problemas de swap e performance.
  • Usar agrupamento de conexões: o agrupamento de conexões ajuda a controlar um grande número de novas conexões tentadas pelo cliente Redis. Analise as diretrizes de práticas recomendadas da AWS para lidar com um grande número de novas conexões.
  • Ajustar limites de tamanho do buffer de saída: você pode ajustar o limite do buffer de saída para controlar o uso do espaço do buffer. Os grupos de parâmetros do ElastiCache para Redis fornecem vários parâmetros que começam com client-output-buffer-limit-* para evitar o crescimento ilimitado do uso do buffer de saída do cliente. Esteja ciente de que não há um limite sugerido para esses parâmetros, pois cada workload é exclusiva. É uma prática recomendada comparar sua workload para que você possa escolher um valor adequado.
  • Considere o uso de mapeamento de hash: no Redis, a área total de memória do Redis DB é linear. É preciso mais memória com menos chaves individuais do que uma única chave mapeada por hash com menos campos. O mapeamento de hash ajuda com estruturas de dados que têm um grande número de chaves. Além do mapeamento de hash, você pode aproveitar a codificação ziplist, que reduz o espaço ocupado pela memória em comparação com as tabelas de hash. Observe que o uso do mapeamento de hash pode causar um pico no uso do mecanismo Redis porque esse é um comando complexo que precisa de mais CPU do que operações definidas.
  • Dimensionar o cluster: às vezes, você pode sentir pressão na memória depois de tomar as precauções necessárias. Se isso ocorrer e o uso for decorrente da workload esperada, considere executar um dimensionamento apropriado para aliviar o gargalo de memória.
  • Defina um alarme para uso de memória. Você pode usar os alarmes do CloudWatch para iniciar um alarme quando o uso da memória ultrapassar um limite predefinido. Use a métrica BytesUsedForCache ou DatabaseMemoryUsagePercentage para criar um alarme no console do CloudWatch para fins de monitoramento e escalabilidade.