Quatro Estratégias Essenciais para Diagnosticar Vazamentos e Picos de Memória no Redis

O Redis é um armazenamento de dados em memória, então problemas de memória aparecem rapidamente. Um pequeno erro no manuseio de TTL, uma lista superdimensionada ou um salvamento em segundo plano em um host sem RAM sobressalente pode se transformar em latência, erros de gravação, despejos, troca (swapping) ou um processo Redis morto pelo sistema operacional.

O primeiro hábito útil é parar de chamar todo aumento de memória de vazamento. Vazamentos verdadeiros no Redis são incomuns. A maioria dos incidentes é uma de três coisas: crescimento real de dados, fragmentação do alocador ou sobrecarga temporária de copy-on-write durante a persistência. Eles parecem semelhantes em um painel, mas as correções são completamente diferentes.

Se used_memory continua subindo, sua aplicação provavelmente está armazenando mais dados do que o esperado. Se used_memory está estável, mas used_memory_rss salta, observe a fragmentação, trabalhos em segundo plano bifurcados (forked) ou o sistema operacional. Se ambos sobem durante um pico de tráfego e nunca caem, verifique TTLs, política de despejo e chaves grandes.

Estratégia 1: Monitoramento Detalhado de Métricas de Uso e Fragmentação

O primeiro passo para diagnosticar qualquer problema de memória é estabelecer uma linha de base e entender como o Redis está reportando o uso de memória. O comando padrão INFO memory fornece métricas essenciais que diferenciam a memória utilizada pelos dados da memória utilizada pelo sistema operacional.

Métricas-chave para diagnóstico

Quando ocorre um pico, observe imediatamente estas métricas do INFO memory:

1. used_memory: memória que o Redis alocou para dados e estruturas internas.
2. used_memory_dataset: memória usada pelo conjunto de dados real, excluindo alguma sobrecarga.
3. used_memory_rss: memória residente que o sistema operacional atribuiu ao processo Redis.
4. mem_fragmentation_ratio: uma comparação aproximada entre RSS e memória alocada. Trate como uma pista, não um veredito.

# Verifique estatísticas básicas de memória
redis-cli INFO memory

# Exemplo de saída
# used_memory:1073741824 			# 1 GB de dados
# used_memory_rss:1509949440 		# ~1.5 GB em RAM
# mem_fragmentation_ratio:1.40625 	# RSS é cerca de 40% maior que used_memory

Interpretando a taxa de fragmentação

Uma taxa próxima de 1.0 geralmente é saudável. Uma taxa acima de 1.5 vale a pena investigar, especialmente se o RSS for alto o suficiente para ameaçar o host. Uma taxa abaixo de 1.0 não prova automaticamente troca (swapping); pode acontecer devido a casos extremos de medição, contabilidade de memória compartilhada ou conjuntos de dados muito pequenos. Verifique as métricas de troca do SO diretamente com vmstat, top, sar ou seu sistema de monitoramento.

Se used_memory está estável, mas o RSS dispara durante BGSAVE ou BGREWRITEAOF, o copy-on-write é uma causa provável. O processo filho está escrevendo um arquivo de persistência enquanto o pai continua lidando com gravações. Páginas alteradas pelo pai podem precisar ser copiadas, o que aumenta temporariamente a pressão sobre a memória.

Estratégia 2: Implementando Políticas de Despejo Robusto

O crescimento ilimitado é a causa única mais frequente de supostos "vazamentos" de memória no Redis. Se a instância é usada como cache, ela deve ter um teto definido para o uso de memória, imposto pela diretiva maxmemory.

Se maxmemory não estiver definido, o Redis pode continuar alocando memória até que o host esteja sob pressão. Em uma máquina Redis dedicada, isso pode terminar com o kernel matando o Redis. Em um contêiner, o runtime do contêiner pode matá-lo mais cedo.

Definindo maxmemory e Seleção de Política

Especifique o limite máximo de memória no seu redis.conf ou usando CONFIG SET:

# Defina a memória máxima para 4 GB. Deixe margem para sobrecarga do Redis,
# processos filhos bifurcados, cache de página do SO e outros processos.
CONFIG SET maxmemory 4gb

# Configure a política de despejo
# allkeys-lru: Despeja as chaves menos recentemente usadas em todo o *conjunto de dados*
CONFIG SET maxmemory-policy allkeys-lru

Nome da Política	Descrição	Caso de Uso
noeviction	Padrão. Retorna erros em comandos de gravação quando o limite de memória é atingido.	Bancos de dados onde nenhuma perda de dados é aceitável.
allkeys-lru	Despeja as chaves menos recentemente usadas, independentemente da expiração.	Cache de propósito geral.
volatile-lru	Despeja as chaves menos recentemente usadas apenas entre aquelas com uma expiração definida.	Casos de uso mistos (dados persistidos + dados de cache).
allkeys-random	Despeja chaves aleatórias quando o limite é atingido.	Armazenamentos de sessão simples ou onde o padrão de acesso é imprevisível.

Para um cache puro, allkeys-lru ou allkeys-lfu é frequentemente um ponto de partida razoável. Para uma instância Redis mista onde apenas algumas chaves são descartáveis, volatile-lru ou outra política volatile-* pode ser mais segura, mas apenas se cada chave de cache tiver uma expiração. A configuração perigosa é um cache com noeviction, sem disciplina de TTL e sem alerta antes que a memória esteja cheia.

Estratégia 3: Diagnosticando e Podando Picos de Chaves Grandes

Às vezes, o problema não é o número de chaves. É uma chave que cresceu sem limite: uma lista de feed de usuário que nunca é truncada, um conjunto ordenado de todos os eventos já vistos ou um hash usado como depósito para campos de sessão.

Usando redis-cli --bigkeys

O utilitário redis-cli --bigkeys escaneia o espaço de chaves e relata chaves grandes por tipo e contagem de elementos. Ele não mede o tamanho exato em bytes e pode adicionar carga em uma instância de produção ocupada, então execute-o com cuidado ou contra uma réplica quando possível.

# Execute a análise de chaves grandes
redis-cli --bigkeys

# Exemplo de Saída (identificando uma Lista massiva)
---------- Summary ----------
...
[5] Biggest list found 'user:1001:feed' with 859387 items

Usando MEMORY USAGE (Redis 4.0+)

Para determinar o tamanho preciso de uma chave suspeita em bytes, use o comando MEMORY USAGE. Isso é vital para diagnósticos aprofundados.

# Verifique o uso de memória de uma chave específica (em bytes)
redis-cli MEMORY USAGE user:1001:feed

# Saída: (ex.) 84329014

Se você identificar chaves grandes, revise o caminho de gravação. Correções comuns são truncar listas com LTRIM, expirar estruturas transitórias, dividir hashes ou conjuntos ordenados muito grandes em partições de chaves menores e substituir leituras "carregar tudo" por acesso paginado, como HSCAN, SSCAN ou ZSCAN. A correção real geralmente está no comportamento da aplicação, não em um botão do Redis.

Estratégia 4: Gerenciando Fragmentação de Memória e Copy-on-Write

Alta fragmentação ou picos repentinos de RSS são frequentemente confundidos com vazamentos de dados. Esses problemas estão relacionados à alocação de memória, rotatividade de objetos e persistência baseada em fork.

Desfragmentação Ativa

A desfragmentação ativa pode ajudar o Redis a recuperar espaço desperdiçado pelo alocador enquanto o servidor continua funcionando. É útil para cargas de trabalho que criam e excluem muitos valores de tamanhos diferentes. Também usa CPU, então habilite deliberadamente e observe a latência após a mudança.

Habilite e configure no redis.conf:

# Habilita a desfragmentação ativa
activedefrag yes

# Os limites inferior e superior são valores de configuração no estilo percentual.
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100

Reduzindo a Sobrecarga de Copy-on-Write

Quando o Redis bifurca (forks) um processo filho para snapshots RDB ou reescritas AOF, o SO usa a otimização CoW. Se o processo pai realiza gravações pesadas enquanto o processo filho está ativo, cada página escrita deve ser duplicada, causando um pico temporário em used_memory_rss. Esse pico pode facilmente dobrar a pegada de memória do Redis.

Passos de Mitigação:

1. Agende a persistência durante períodos de baixo tráfego.
2. Deixe margem de memória acima de maxmemory para sobrecarga do alocador, clientes, buffers de replicação e processos filhos bifurcados. A margem correta depende do tamanho do conjunto de dados e da taxa de gravação; meça durante um BGSAVE ou BGREWRITEAOF real.
3. Evite sobrepor trabalhos pesados em segundo plano, como snapshots, reescritas AOF, backups e varreduras em nível de host.
4. Reduza a rotatividade de gravação durante a persistência se um trabalho em lote estiver causando crescimento de copy-on-write.

Não recorra a variáveis de ambiente do alocador como primeira resposta. O Redis é comumente construído com jemalloc, e alterar o comportamento do alocador sem teste pode criar nova latência ou comportamento de memória. Se a fragmentação permanecer severa após a desfragmentação ativa e correções na carga de trabalho, teste as alterações em uma instância de teste ou réplica antes de tocar na produção.

Um fluxo de incidente prático

Quando a memória saltar, colete os fatos antes de reiniciar o Redis. Uma reinicialização pode esconder as evidências.

Execute:

redis-cli INFO memory
redis-cli INFO persistence
redis-cli DBSIZE
redis-cli --bigkeys

Então pergunte o que mudou. Um deploy removeu TTLs? Um consumidor de fila parou, fazendo as listas crescerem? Um novo trabalho de relatório executou HGETALL em hashes enormes? Uma reescrita AOF começou durante o pico de tráfego? O limite de memória do contêiner mudou?

As melhores correções de memória do Redis são geralmente simples: defina um maxmemory realista, escolha uma política de despejo que corresponda à carga de trabalho, dê a cada chave de cache um TTL, quebre estruturas ilimitadas, evite que a persistência seja executada sem margem de memória e alerte sobre tendências de memória antes que a instância atinja o limite.