Tutorial: Redis consumindo muita RAM no AlmaLinux 9

19 min de leitura  ·  Guia técnico

Redis consumindo muita RAM é um problema comum em servidores AlmaLinux 9 que executam aplicações web com cache intensivo. O consumo excessivo ocorre principalmente pela ausência de limite de memória configurado, acúmulo de chaves sem TTL e fragmentação interna. Para identificar e reduzir o uso de RAM do Redis, siga estes passos:

1. Conecte ao Redis CLI e execute INFO memory para obter o diagnóstico inicial.
2. Identifique chaves grandes com redis-cli --bigkeys.
3. Configure maxmemory e maxmemory-policy no arquivo /etc/redis/redis.conf.
4. Ative a desfragmentação automática com activedefrag yes.
5. Reinicie o serviço e monitore o consumo com redis-cli INFO memory.

Pré-requisitos

• Sistema operacional: AlmaLinux 9 (testado com AlmaLinux 9.3 e 9.4).
• Redis: versão 7.x instalada via repositório oficial ou EPEL.
• Acesso root ou usuário com privilégios sudo ao servidor.
• redis-cli disponível no PATH (instalado junto ao pacote redis).
• Acesso SSH ao servidor — consulte como acessar servidores VPS Linux da AviraHost caso precise de orientação.
• Editor de texto como vim ou nano para editar arquivos de configuração.

Como diagnosticar o Redis consumindo muita RAM no AlmaLinux 9

Antes de aplicar qualquer ajuste, é fundamental entender o que está causando o alto consumo de memória no Redis. O comando INFO memory é o ponto de partida obrigatório para qualquer diagnóstico de uso de RAM no Redis.

Conecte ao Redis CLI como root:

redis-cli

Dentro do prompt interativo, execute:

INFO memory

Você verá uma saída semelhante a esta:

# Memory
used_memory:524288000
used_memory_human:500.00M
used_memory_rss:671088640
used_memory_rss_human:640.00M
used_memory_peak:671088640
used_memory_peak_human:640.00M
mem_fragmentation_ratio:1.28
mem_allocator:libc
active_defrag_running:0
lazyfree_pending_objects:0

Os campos mais importantes para análise são:

• used_memory_human: memória efetivamente usada pelo Redis para armazenar dados.
• used_memory_rss_human: memória alocada pelo sistema operacional para o processo Redis — inclui fragmentação.
• mem_fragmentation_ratio: razão entre RSS e used_memory. Valores acima de 1.5 indicam fragmentação elevada; valores abaixo de 1.0 indicam que o Redis está usando swap.
• used_memory_peak_human: pico histórico de uso — útil para dimensionar o limite máximo.

Para verificar quantas chaves existem no banco de dados atual e em todos os bancos:

INFO keyspace

# Keyspace
db0:keys=48320,expires=12100,avg_ttl=86400000

Neste exemplo, existem 48.320 chaves no banco 0, mas apenas 12.100 possuem TTL definido. As 36.220 chaves restantes nunca expiram e acumulam memória indefinidamente — um dos cenários mais comuns de crescimento descontrolado de RAM.

Para identificar as maiores chaves por tipo de dado, execute fora do prompt interativo:

redis-cli --bigkeys

Scanning the entire keyspace to find biggest keys as well as
average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
per 100 SCAN commands (reduces server load).

[00.00%] Biggest string found so far "session:user:9821" with 512 bytes
[00.00%] Biggest hash   found so far "cache:product:list" with 18420 fields
[00.00%] Biggest list   found so far "queue:emails" with 94210 items

-------- summary -------
Sampled 48320 keys in the keyspace!
Total key length in bytes is 1843200 (avg len 38.14)
Biggest   list found "queue:emails" has 94210 items
Biggest   hash found "cache:product:list" has 18420 fields
Biggest string found "session:user:9821" has 512 bytes

Com este relatório, você identifica candidatos imediatos para compressão, paginação ou remoção. Uma lista com 94.210 itens acumulados em memória é um sinal claro de que o consumidor da fila não está processando os itens na velocidade adequada.

Configurando maxmemory e política de eviction para controlar o uso de RAM

A política de eviction do Redis define o comportamento quando o limite de memória é atingido. Sem essa configuração, o Redis cresce indefinidamente até esgotar a RAM disponível do servidor, causando uso de swap ou até OOM killer do Linux.

Abra o arquivo de configuração principal do Redis:

sudo vim /etc/redis/redis.conf

Localize e ajuste as seguintes diretivas (use /maxmemory para buscar no vim):

maxmemory 512mb
maxmemory-policy allkeys-lru

As políticas de eviction disponíveis no Redis 7.x são:

• noeviction: retorna erro quando a memória está cheia — padrão, inadequado para cache.
• allkeys-lru: descarta qualquer chave usando o algoritmo LRU (Least Recently Used) — ideal para cache geral.
• volatile-lru: descarta apenas chaves com TTL definido usando LRU — ideal para cache de sessão PHP.
• allkeys-lfu: descarta chaves menos frequentemente usadas — melhor para workloads com acesso desigual.
• volatile-ttl: descarta chaves com TTL mais curto primeiro — útil quando a expiração é critério de prioridade.
• allkeys-random: descarta chaves aleatórias — não recomendado para a maioria dos casos.

Para ambientes que usam Redis exclusivamente como cache (sem persistência de dados críticos), allkeys-lru é a escolha mais segura. Para aplicações que misturam cache e dados persistentes sem TTL, use volatile-lru.

Após editar o arquivo, salve e reinicie o serviço:

sudo systemctl restart redis

Verifique se o serviço subiu corretamente:

sudo systemctl status redis

● redis.service - Redis persistent key-value database
     Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; preset: disabled)
     Active: active (running) since Mon 2024-11-04 14:32:11 UTC; 3s ago
   Main PID: 18432 (redis-server)
      Tasks: 5 (limit: 4915)
     Memory: 512.1M
        CPU: 0.124s
     CGroup: /system.slice/redis.service
             └─18432 /usr/bin/redis-server 127.0.0.1:6379

Confirme que o limite foi aplicado:

redis-cli CONFIG GET maxmemory

1) "maxmemory"
2) "536870912"

O valor 536870912 corresponde a 512 MB em bytes — confirmação de que a configuração foi aplicada com sucesso.

Corrigindo fragmentação de memória no Redis com activedefrag

A fragmentação de memória no Redis é um fenômeno silencioso que pode fazer o processo consumir significativamente mais RAM do que os dados realmente ocupam. Quando o mem_fragmentation_ratio ultrapassa 1.5, o Redis está desperdiçando memória em lacunas não reutilizáveis.

O Redis 7.x no AlmaLinux 9 suporta desfragmentação ativa em tempo real. Para ativá-la, edite novamente o redis.conf:

sudo vim /etc/redis/redis.conf

Adicione ou descomente as seguintes diretivas:

activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-enabled yes
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100
active-defrag-cycle-min 1
active-defrag-cycle-max 25

Explicação de cada parâmetro:

• activedefrag yes: ativa a desfragmentação automática em background.
• active-defrag-ignore-bytes 100mb: só inicia a desfragmentação se houver pelo menos 100 MB de fragmentação.
• active-defrag-threshold-lower 10: inicia quando a fragmentação supera 10%.
• active-defrag-threshold-upper 100: usa CPU máxima quando a fragmentação atinge 100%.
• active-defrag-cycle-min/max: controla o percentual de CPU dedicado ao processo de desfragmentação.

Você também pode ativar a desfragmentação em tempo real sem reiniciar o serviço:

redis-cli CONFIG SET activedefrag yes

Após alguns minutos, monitore o efeito:

redis-cli INFO memory | grep -E "used_memory_human|mem_fragmentation_ratio|active_defrag"

used_memory_human:312.40M
mem_fragmentation_ratio:1.08
active_defrag_running:1

Um mem_fragmentation_ratio próximo de 1.0 indica que a desfragmentação está funcionando corretamente.

Removendo chaves sem TTL e otimizando o uso de memória por tipo de dado

Além das configurações de limite e desfragmentação, eliminar chaves desnecessárias sem TTL é uma das ações mais eficazes para reduzir o consumo de RAM do Redis de forma permanente.

Para listar chaves sem TTL em um banco específico (use com cautela em produção):

redis-cli --scan --pattern "*" | while read key; do
  ttl=$(redis-cli TTL "$key")
  if [ "$ttl" -eq -1 ]; then
    echo "Sem TTL: $key"
  fi
done

Atenção: em bases com milhões de chaves, este script pode gerar carga significativa no servidor. Execute preferencialmente em horários de baixo tráfego ou use redis-cli --scan com a opção -i 0.1 para adicionar delay entre os comandos.

Para definir TTL em chaves existentes que não possuem expiração:

redis-cli EXPIRE "cache:product:list" 3600

Para remover uma chave específica que não é mais necessária:

redis-cli DEL "queue:emails"

Outra técnica importante é usar estruturas de dados mais eficientes. O Redis oferece tipos compactos que consomem menos memória:

• Hash com poucos campos: o Redis usa ziplist internamente para hashes com menos de 128 campos e valores menores que 64 bytes, consumindo até 10x menos memória que strings individuais.
• Sorted sets pequenos: também usam ziplist quando abaixo dos limites configurados em zset-max-ziplist-entries e zset-max-ziplist-value.
• Compressão de valores: para strings grandes, considere comprimir no lado da aplicação antes de armazenar no Redis.

Para verificar o uso de memória de uma chave específica:

redis-cli MEMORY USAGE "cache:product:list"

(integer) 2847392

O valor retornado é em bytes — neste caso, aproximadamente 2.7 MB para uma única chave hash.

Para otimizar os limites de ziplist no redis.conf:

hash-max-ziplist-entries 128
hash-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
list-max-ziplist-size -2

Se você também gerencia banco de dados no mesmo servidor, vale conferir as dicas de otimização de servidores Linux para uma abordagem integrada de uso de recursos.

Monitoramento contínuo do consumo de RAM do Redis

Configurar limites e políticas resolve o problema imediato, mas o monitoramento contínuo do Redis é essencial para evitar recorrências. O Redis oferece ferramentas nativas para acompanhar o comportamento em tempo real.

Para monitorar estatísticas em tempo real a cada 2 segundos:

redis-cli --stat

------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections
48320      312.40M  12      0       1284832 (+0)        847
48320      312.41M  12      0       1284901 (+69)       847
48318      312.38M  12      0       1284970 (+69)       847

Para monitorar comandos executados em tempo real (útil para identificar padrões de escrita excessiva):

redis-cli MONITOR

Atenção: o comando MONITOR captura todos os comandos e pode reduzir o desempenho do Redis em até 50% em ambientes de alta carga. Use apenas para diagnóstico pontual e encerre com Ctrl+C.

Para verificar estatísticas de eviction (quantas chaves foram descartadas pela política configurada):

redis-cli INFO stats | grep evicted

evicted_keys:1842

Um número crescente de evicted_keys indica que o Redis está atingindo o limite de memória com frequência. Se o valor crescer rapidamente, considere aumentar o maxmemory ou revisar a arquitetura de cache da aplicação.

Para automatizar o monitoramento, crie um script simples de alerta:

#!/bin/bash
USED=$(redis-cli INFO memory | grep "used_memory:" | awk -F: '{print $2}' | tr -d '\r')
MAX=$(redis-cli CONFIG GET maxmemory | tail -1)
PERCENT=$(echo "scale=2; $USED * 100 / $MAX" | bc)
echo "Redis usando ${PERCENT}% do limite de memória configurado"
if (( $(echo "$PERCENT > 85" | bc -l) )); then
  echo "ALERTA: Redis acima de 85% da memória máxima!" | mail -s "Alerta Redis RAM" [email protected]
fi

Salve como /usr/local/bin/check-redis-mem.sh, torne executável e adicione ao cron:

chmod +x /usr/local/bin/check-redis-mem.sh
echo "*/15 * * * * root /usr/local/bin/check-redis-mem.sh" >> /etc/cron.d/redis-monitor

Problemas comuns e como resolver

Sintoma: Redis reinicia automaticamente com erro OOM killer

Causa: o processo Redis foi encerrado pelo kernel do Linux por consumo excessivo de RAM sem limite configurado. O OOM (Out of Memory) killer termina processos para proteger o sistema operacional.
Solução: configure imediatamente o maxmemory no redis.conf com um valor seguro (geralmente 50-70% da RAM disponível para servidores dedicados ao Redis). Verifique os logs do kernel com dmesg | grep -i "oom\|killed" para confirmar o diagnóstico. Após configurar o limite, reinicie o Redis com systemctl restart redis.

Sintoma: mem_fragmentation_ratio muito alto (acima de 2.0) mesmo após ativar activedefrag

Causa: fragmentação severa pode ocorrer quando o Redis passou por picos de carga com muitas operações de escrita e deleção em sequência. O alocador padrão libc no AlmaLinux 9 é menos eficiente que o jemalloc para gerenciar fragmentação.
Solução: instale o Redis compilado com suporte a jemalloc (o pacote do EPEL já inclui) e verifique com redis-cli INFO memory | grep mem_allocator. Se o alocador for libc, considere recompilar o Redis ou usar o pacote do repositório Remi. Como solução imediata, reiniciar o Redis com systemctl restart redis libera a memória fragmentada, mas causa breve indisponibilidade.

Sintoma: Redis não descarta chaves mesmo com maxmemory-policy configurado

Causa: a política volatile-lru ou volatile-ttl só descarta chaves que possuem TTL definido. Se todas as chaves forem persistentes (sem TTL), o Redis não consegue despejar nenhuma e retorna erro OOM command not allowed when used memory > 'maxmemory'.
Solução: mude a política para allkeys-lru se o Redis for usado exclusivamente como cache, ou defina TTL nas chaves existentes com o comando EXPIRE. Verifique a política atual com redis-cli CONFIG GET maxmemory-policy.

Sintoma: consumo de RAM cresce gradualmente mesmo com maxmemory configurado

Causa: o valor de used_memory_rss pode crescer além do maxmemory devido à fragmentação e ao overhead interno do Redis (buffers de cliente, estruturas internas). O maxmemory controla apenas os dados armazenados, não o consumo total do processo.
Solução: configure maxmemory com uma margem de segurança de 20-30% abaixo da RAM disponível. Ative activedefrag yes e monitore o mem_fragmentation_ratio regularmente. Reduza o número máximo de clientes conectados com maxclients 100 se houver muitas conexões simultâneas.

Perguntas frequentes sobre Redis consumindo muita RAM

Por que o Redis consome tanta memória mesmo com poucos dados?

O Redis mantém todos os dados na RAM por design, mas o consumo excessivo geralmente indica ausência de política de eviction configurada, acúmulo de chaves sem TTL ou fragmentação interna de memória. Verificar o output de INFO memory e ajustar maxmemory com uma política como allkeys-lru resolve a maioria dos casos. Além disso, o overhead de estruturas internas do Redis (buffers de cliente, metadados de chaves) pode representar 10-30% do consumo total mesmo com poucos dados armazenados.

Como limitar a memória máxima que o Redis pode usar?

Edite o arquivo /etc/redis/redis.conf e defina a diretiva maxmemory com o valor desejado, por exemplo maxmemory 512mb. Em seguida, configure maxmemory-policy para allkeys-lru ou volatile-lru e reinicie o serviço com systemctl restart redis. O Redis passará a despejar chaves automaticamente ao atingir o limite. Você também pode aplicar a configuração sem reiniciar usando redis-cli CONFIG SET maxmemory 536870912, mas a alteração não persiste após reinicialização sem editar o arquivo de configuração.

O que é fragmentação de memória no Redis e como corrigir?

Fragmentação ocorre quando o Redis aloca e libera blocos de memória de tamanhos variados, deixando lacunas que o alocador não consegue reutilizar imediatamente. O indicador mem_fragmentation_ratio acima de 1.5 no INFO memory sinaliza fragmentação elevada. Ativar activedefrag yes no redis.conf permite que o Redis desfragmente a memória em tempo real sem reinicialização, sendo a solução preferida para ambientes de produção onde a indisponibilidade não é aceitável.

Qual política de eviction do Redis é mais indicada para cache de sessão PHP?

Para cache de sessão PHP, a política volatile-lru é a mais indicada porque descarta apenas chaves que possuem TTL definido, preservando dados persistentes sem expiração. Se todas as chaves tiverem TTL, allkeys-lru também funciona bem e oferece maior flexibilidade ao Redis para liberar memória quando necessário. A escolha entre as duas depende de como a aplicação PHP gerencia as sessões — se usa session.gc_maxlifetime com TTL explícito no Redis, volatile-lru é mais seguro.

Como verificar quais chaves do Redis estão ocupando mais memória?

Execute redis-cli --bigkeys para obter um relatório das maiores chaves por tipo de dado. Para análise mais detalhada de uma chave específica, use redis-cli MEMORY USAGE nome-da-chave, que retorna o consumo exato em bytes incluindo overhead de estrutura. Para análise completa do dump RDB, ferramentas como rdb-tools permitem gerar relatórios detalhados de todas as chaves sem impactar o servidor em produção. Identificar chaves grandes permite decidir entre compressão, paginação ou remoção de dados desnecessários.

Conclusão

Controlar o Redis consumindo muita RAM no AlmaLinux 9 envolve três frentes complementares que devem ser aplicadas em conjunto:

• Diagnóstico preciso: use INFO memory, --bigkeys e MEMORY USAGE para entender a origem do consumo antes de aplicar qualquer mudança.
• Configuração de limites e eviction: defina maxmemory com margem de segurança e escolha a política de eviction adequada ao tipo de workload — allkeys-lru para cache puro, volatile-lru para ambientes mistos.
• Monitoramento contínuo: implemente alertas automáticos e verifique regularmente o mem_fragmentation_ratio para agir antes que o consumo se torne crítico.

Leia também

• Otimizar o uso de memória RAM no MySQL em VPS Linux e servidores dedicados
• Passo a passo para auditoria de segurança no AlmaLinux 9
• Comparativo: Varnish vs Redis como cache HTTP no Debian 12

Precisa de ajuda com Redis e otimização de servidor?

Configurar Redis em produção exige atenção a detalhes que variam conforme o workload da sua aplicação. Um VPS com recursos adequados e suporte técnico especializado faz diferença na estabilidade do ambiente.

Conheça os planos de VPS da AviraHost com suporte técnico em português