Práticas recomendadas para o gerenciamento de memória

Nesta página, explicamos como gerenciar o uso de memória da sua instância com recomendações de validade de chave, monitoramento de métricas e configurações de remoção de chave para diferentes casos de uso do Cloud Memorystore para Redis. Essas recomendações ajudam a evitar e reduzir os erros de falta de memória (OOM, na sigla em inglês).

A política de consumo máximo de memória padrão é volatile-lru. Consulte Como configurar instâncias do Redis para mais instruções sobre como alterar essa política.

Causas dos erros de OOM

Veja a seguir os padrões de uso que podem contribuir para que sua instância fique sem memória e gere o erro de OOM:

  • Grande volume de gravação de aplicativos com tamanho de instância insuficiente
  • Uma política de consumo máximo de memória inadequada
  • Configurações da validade da chave inadequadas

Alerta do Stackdriver

Defina um alerta para receber notificações quando o uso da memória da instância exceder 50%. Nesse caso, monitore o uso regularmente e avalie a possibilidade de escalonar o tamanho da instância.

Métricas de uso de memória de instâncias

Quando você cria uma instância do Cloud Memorystore para Redis, escolhe um tamanho de instância para armazenar seus dados do Redis. O Cloud Memorystore para Redis provisiona uma instância com uma memória total do sistema maior que o tamanho da instância para executar a infraestrutura interna que mantém a instância em pleno funcionamento.

Quando você soma a memória usada pelos seus dados do Redis e a memória usada pela infraestrutura interna, o resultado é o uso de memória do sistema. Para ver a proporção entre o uso de memória do sistema e a memória total do sistema, consulte a métrica da proporção de uso de memória do sistema no Stackdriver Metrics Explorer. Uma proporção de 0.3 significa que os dados do Redis e a infraestrutura interna ocupam 30% da memória disponível do sistema.

Se a métrica de proporção de uso da memória do sistema da sua instância alcançar 0.9, sua instância pode parar de responder e precisar ser reiniciada, o que pode causar perda de dados. Para que isso não aconteça, defina um alerta do Stackdriver para receber uma notificação se a proporção de uso da memória do sistema alcançar 50%. Se isso acontecer, monitore atentamente essa métrica e considere escalonar sua instância se o uso de memória aumentar muito.

Além da proporção de uso da memória do sistema, o Stackdriver também fornece a métrica de proporção de uso da memória, que exibe a proporção atual entre dados do Redis armazenados e o tamanho da instância, definido durante a criação dela. Uma proporção de 0.3 significa que seus dados do Redis usam 30% do tamanho da sua instância. A métrica de proporção de uso da memória pode chegar a 1.0. Nesse caso, os dados do Redis ocuparam a memória inteira e uma das políticas de consumo máximo de memória, descritas nas configurações do Redis, entra em vigor com base nas configurações da sua instância.

Como remover chaves

O Redis remove chaves por meio de ações solicitadas pelo cliente como exclusão (DEL, conteúdo em inglês), expiração (EXPIRE, conteúdo em inglês), configuração (SET com EX, conteúdo em inglês) ou remoção. As chaves terão validade somente se você definir a TTL delas. Quando a TTL chega ao fim, o Redis remove a respectiva chave de maneira assíncrona. Para mais detalhes sobre como o Redis faz isso, consulte a documentação do comando EXPIRE do Redis (em inglês).

Se a memória da instância estiver cheia e uma nova gravação for feita, o Redis removerá as chaves de acordo com a política de consumo máximo de memória da instância para liberar espaço suficiente para a gravação.

Práticas recomendadas de gerenciamento de dados

Como identificar chaves voláteis e não voláteis

É possível usar o Cloud Memorystore para Redis para armazenar tanto chaves voláteis quanto não voláteis. As chaves voláteis referem-se a valores que você espera que permaneçam na instância do Redis temporariamente, como valores de cache ou expiráveis. As chaves não voláteis são valores que você pretende manter no Redis por um longo período.

Por exemplo, as pontuações de um placar de um jogo de videogame, as sessões do usuário em sites e os preços de ações são dados voláteis porque têm valores válidos apenas por um curto período. É preciso definir a TTL das chaves voláteis.

Alguns exemplos de dados não voláteis incluem o total de visitas de um site ou a configuração de um mapa. Não defina a TTL nesses casos. Esses dados precisarão permanecer no Redis por um longo período.

Como gerenciar uma combinação entre dados voláteis e não voláteis

Sempre que possível, separe os dados voláteis dos não voláteis em instâncias diferentes do Redis. Assim, é possível configurar cada caso de uso individualmente.

Se você decidir usar uma instância para dados voláteis e não voláteis, basta definir a TTL nas chaves específicas e usar uma das políticas de consumo máximo de memória volatile. Em comparação com as voláteis, as chaves não voláteis precisam ser pequenas.

Contanto que você não adicione ou remova dados não voláteis com frequência, a proporção entre as chaves expiráveis e as não expiráveis precisa ser estável. É possível calcular a porcentagem de chaves expiráveis em relação a todas as chaves usando métricas do Stackdriver. No seu painel do Stackdriver, localize as métricas de chaves expiráveis e de total de chaves. Divida a métrica de total de chaves pela de chaves expiráveis para chegar à proporção esperada.

Se você perceber uma queda inesperada na proporção de chaves expiráveis, pode ser que seu cliente esteja deixando de definir a TLL para algumas chaves. Nesse caso, o Redis não remove essas chaves e mantém os dados delas ativos, assim como os dados não voláteis. Com o tempo, isso reduz continuamente o espaço de armazenamento destinado a valores em cache a tal ponto que todas as chaves não voláteis e gravações apresentam falhas.

Se você perceber que a porcentagem de chaves voláteis está diminuindo de maneira inesperada, use o comando RANDOMKEY (conteúdo em inglês) do Redis para receber amostras de chaves e localizar a origem das chaves não voláteis. É possível também usar o comando SCAN (conteúdo em inglês) do Redis para localizá-las.

Como gerenciar dados voláteis

Use uma das políticas de consumo máximo de memória volatile e defina a TTL de todos os dados voláteis. A definição de uma TTL mais longa aumenta a proporção de ocorrência em cache, o que reduz a carga nos servidores, back-end e bancos de dados. No entanto, talvez seja necessário ter uma instância maior, já que é possível que você fique sem memória se houver uma grande carga de gravação e uma TTL longa. A TTL mais curta tem o efeito inverso.

Normalmente, você precisa definir todas as suas chaves com a mesma TTL. Para ver a TTL média de uma amostra de chaves, acesse o Metrics Explorer do Stackdriver e gere um gráfico da métrica de TTL média da sua instância. Espera-se que um cache saudável tenha uma TTL média equivalente a metade da TTL máxima.

Se a instância atingir o consumo máximo de memória, a política em questão removerá as chaves antes que a validade delas seja configurada, o que aproxima a TTL média da máxima. Se você notar que houve uma elevação na proporção de remoção, recomendamos aumentar a memória da instância do Redis para que as ocorrências em cache aumentem.

Como gerenciar dados que podem ser armazenados em cache sem validade

Use a política allkeys-lru para armazenar em cache os dados que não são temporais por natureza ou que não expiram em um tempo razoável. Como alternativa, se a instância estiver executando o Redis versão 4.0 ou posterior, use allkeys-lfu.

Veja, por exemplo, o armazenamento em cache de postagens de blog com os respectivos URLs. As postagens não expiram sozinhas. A maioria delas acaba se tornando menos relevante, mas algumas podem continuar sendo muito acessadas.

Sua instância do Redis pode armazenar apenas uma quantidade finita de dados de postagens de blog. Por conta disso, quando sua instância ficar cheia, a política allkeys-lru ou allkeys-lfu acabará removendo as chaves que forem usadas com menos frequência. Essa política de consumo máximo de memória mantém os dados mais solicitados na instância do Redis.

Se você achar que a proporção de ocorrência em cache é muito baixa, defina uma meta para ela e aumente o tamanho da instância até alcançar a meta. No caso de algumas cargas de trabalho, pode levar vários dias para alcançar uma proporção de ocorrência em cache estável.

Métrica

Proporção de ocorrência em cache para allkeys-lru

Sua proporção de ocorrência em cache precisa estar aproximadamente entre 50% e 98%. Se ela diminuir, isso indicará que há ausência de cache. Se a proporção for estável e menor que 50%, escalone para uma instância maior.

Se você optar por não escalonar para aumentar o valor da proporção, sua instância do Redis continuará a exibir as chaves usadas com mais frequência, mas você poderá perder oportunidades de armazenamento em cache e ter uma carga mais cara no sistema devido à ausência de cache.

Proporção de ocorrência em cache para volatile-lru e volatile-ttl

A proporção de ocorrência em cache pode ser baixa ou decrescente para as políticas volatile-lru e volatile-ttl de consumo máximo de memória devido ao tamanho insuficiente da instância.

Além disso, a proporção de ocorrência em cache pode diminuir porque o aplicativo define as chaves sem uma TTL. Se esse for o caso, defina a TTL dessas chaves para que elas expirem.

Outras métricas

As métricas de chaves expiráveis e chaves removidas, localizadas na página do Metrics Explorer do Stackdriver do seu projeto, disponibilizam mais informações sobre a remoção de chaves da instância. Rastreie as chaves removidas por segundo para descobrir a proporção de remoção da sua instância.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Google Cloud Memorystore para Redis